标签：#React

What happens when 5 parallel API calls hit for an expired JWT at the exact same millisecond. Imagine this: You’ve built a sleek, high-performance React dashboard. The UI is sharp, dark mode is gleaming, components are modularized, and React Query is executing parallel data fetches like a grand symphony. You brew a cup of coffee, open the app after lunch, hit refresh, and… BAM! You are immediately booted back to the Login screen. No warnings, no friendly error toasts—just a cold, ruthless redirect. You check your JWT expiration timer. The access token died 5 seconds ago, but your refresh token is valid for another 14 days. So why on earth did your app decide to kick you out like an uninvited party crasher? Welcome to the chaotic nightmare of Token Refresh Race Conditions in Axios Interceptors . In this article, we’ll walk through how parallel React queries can accidentally DDOS your own backend, why standard interceptor tutorials fail in production, how we built a promise-queue lock mechanism to solve it, and the subtle "gotcha" lurking in simple error detail checks that almost broke everything anyway. 1. The Problem: The Dashboard Stampede When a user logs into our app and opens the main dashboard, React Query triggers a stampede of concurrent API requests: GET /api/teams/users/ (Fetch team members) GET /api/teams/addresses/ (Fetch locations) GET /api/auth/profile/ (Fetch user profile) GET /api/auth/activity/recent/ (Fetch activity log) GET /api/notifications/ (Fetch unread alerts) Under normal circumstances, all five requests ride happily on the same valid Bearer <access_token> HTTP header. React App ---------------------------------------------> Django Backend GET /users/ [Bearer valid] ---> 200 OK GET /locations/ [Bearer valid] ---> 200 OK GET /profile/ [Bearer valid] ---> 200 OK The Ticking Time Bomb Fast forward 15 minutes. The short-lived access token expires. The user clicks on the "Analytics" tab. All 5 queries trigger at the exact same millisecond ( T = 0ms

Jotai v2.20.0 has been released, focusing on improved performance for high-throughput scenarios. Key changes involve adjustments to internal building blocks and addressing previous performance regressions. While the API for everyday use remains unchanged, library authors should note some deprecations as the groundwork for Jotai v3 begins. By Daniel Curtis

~7 min read · Tutorial I look at a lot of MUI admin templates. material-kit-react from the minimals people is one I keep going back to. Clean, typed, and the folder structure makes sense. Repo: minimal-ui-kit/material-kit-react . But every time I just want to see it, or change one color to check something, it's the same ritual. git clone , npm install , wait, npm run dev , wait more, tab over to localhost. Few minutes gone, a few hundred MB of node_modules on disk. All that to look at a dashboard. So this time I skipped the build. Opened the folder in CrossUI Studio , rendered src/main.tsx directly. No install, no Vite, no localhost. Below is what I did, including the bits that made me stop and think. One honest note first. This does not replace your dev server. You still need the real thing for tests, prod builds, actual feature work. It's good for the look-and-tweak loop. Evaluating a template, recoloring something, showing a client. The stuff where booting the whole toolchain costs more than the task itself. Quick note : local folder support requires a Pro account. To test it out, use the code in the original blog for a free upgrade. No credit card required, available while it lasts. Your browser does not support video. Watch on YouTube . 1. Clone to local disk (don't open it straight from GitHub) Studio can mount a GitHub repo directly. For a small repo that's the nicest path. For this one I cloned to disk first: git clone https://github.com/minimal-ui-kit/material-kit-react The reason is boring. src/ alone is ~130 files, ~245 in the whole project, spread over sections/ , components/ , layouts/ , theme/ , routes/ . Opening a project means the tool has to pull the files it touches. Over the GitHub API, on demand, that's a lot of small requests. It works, just not snappy, and you can hit the rate limit if you poke around. A local folder is only the filesystem, so it's instant. For a template this size, local wins. No npm install here. I only cloned the source. The

If you ship a React Native / Expo app to the App Store, you know the ritual. Open the Apple Developer portal, create a bundle identifier, tick the capability checkboxes, generate a provisioning profile, pick the right certificate. Then hop over to the Expo dashboard, create the EAS app, wire up credentials, add your environment variables one screen at a time. It works, until you have to do it again for a second app, or a second environment, or a teammate needs to know why a capability is enabled. None of it is written down. It drifts. And the usual mobile tooling doesn't help much here: fastlane and the EAS CLI are great, but they're imperative — scripts that do things — not a declarative description of what your release setup should be . That's the gap these two providers fill: elevenode/appstore — App Store Connect: bundle identifiers, provisioning profiles, certificates. elevenode/expo — Expo Application Services (EAS): apps, credentials, environment variables, update channels. Both are open source (Apache 2.0) and published on the Terraform Registry. Let's use them together to describe a mobile app's release setup as code. What you'll need Terraform (or OpenTofu) An App Store Connect API key (Users and Access → Integrations → App Store Connect API): the key, its key ID, and your issuer ID An Expo access token (expo.dev → account settings → Access Tokens) and your Expo account name Export the credentials as environment variables so nothing sensitive lands in your config: export APPSTORE_KEY = " $( cat AuthKey_XXXX.p8 ) " export APPSTORE_KEY_ID = "XXXXXXXXXX" export APPSTORE_KEY_ISSUER_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" export EXPO_TOKEN = "your-expo-access-token" export EXPO_ACCOUNT_NAME = "your-account-name" Wiring up both providers terraform { required_providers { appstore = { source = "elevenode/appstore" } expo = { source = "elevenode/expo" } } } # Reads APPSTORE_KEY / APPSTORE_KEY_ID / APPSTORE_KEY_ISSUER_ID from the env. provider "appstore" {} # Re

If you've been developing with React Native or Expo for a while, chances are you've had a project that suddenly refuses to build for what seems like no reason. Maybe you installed a new package. Maybe you upgraded Expo. Maybe you only changed a single dependency. You confidently run your Android build, expecting it to compile like always... Instead, Gradle greets you with something like this: Execution failed for task ':app:checkDebugDuplicateClasses'. Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.8.2.aar and lifecycle-viewmodel-ktx-2.6.1.aar Duplicate class com.google.android.gms.internal.measurement.zzab found in modules play-services-measurement-base-22.0.0.aar and play-services-measurement-impl-21.6.2.aar Duplicate class ... At first glance, the error looks straightforward: there are duplicate classes . Easy enough, right? Not exactly. In reality, this is one of those Android build errors that can send you down a rabbit hole of Gradle files, dependency trees and Stack Overflow threads, only to realize the real cause was something completely different. Let's break down what's actually happening and, more importantly, how to fix it. Why this error happens Every Android library included in your project contains compiled Java or Kotlin classes. When Gradle builds your application, it combines all of those libraries into a single APK or AAB. If two different dependencies contain the exact same class, Gradle doesn't know which version should be packaged. Instead of guessing, it stops the build with a Duplicate class error. The difficult part is that the dependency causing the conflict usually isn't the one shown in the error. Very often, it's another package pulling in an older or incompatible version behind the scenes. The most common causes After seeing this error many times, these are usually the culprits. 1. Two libraries depend on different versions of the same package This is by far the most common scenario. For example:

Next.js 16 shipped Cache Components - the feature that finally lets a single route mix static HTML, cached data, and per-request dynamic content without splitting it into separate pages. It is Partial Prerendering (PPR) made stable, plus a new use cache directive that replaces the old unstable_cache and the awkward route-segment config flags. This guide covers what changed, the three content types you now think in, and the runtime-data rule that trips up almost everyone on day one. What actually changed If you were using the experimental PPR flag, it is gone. Cache Components is a single config switch, and it turns on the whole model - static shell, cached segments, and streamed dynamic content in one route. // next.config.ts import type { NextConfig } from ' next ' const nextConfig : NextConfig = { cacheComponents : true , // replaces experimental.ppr } export default nextConfig Once it is on, every piece of your route falls into one of three buckets. The whole mental model is learning which bucket each component belongs in. The three content types Static - synchronous code, imports, and pure markup. Prerendered at build time and served instantly from the CDN. Your header, nav, and layout shell. Cached - async data that does not need to be fresh on every request. Marked with use cache . Think product lists, blog posts, dashboard stats. Dynamic - runtime data that must be fresh (cookies, headers, per-user state). Wrapped in Suspense so it streams in after the shell paints. import { Suspense } from ' react ' import { cookies } from ' next/headers ' import { cacheLife } from ' next/cache ' export default function DashboardPage () { return ( <> { /* Static - instant from the CDN */ } < header >< h1 > Dashboard </ h1 ></ header > { /* Cached - fast, revalidates hourly */ } < Stats /> { /* Dynamic - streams in with fresh data */ } < Suspense fallback = { < NotificationsSkeleton /> } > < Notifications /> </ Suspense > </> ) } async function Stats () { ' use cache ' cacheL

Meta's React library has integrated a Rust version of the React Compiler into its main repository, aimed at enhancing build speed and compatibility with the Rust-based JavaScript toolchain. This port, which memoizes components automatically, demonstrates significant performance improvements, boasting up to 50% faster compilation. The public API remains unchanged to facilitate easy upgrades. By Daniel Curtis

I'm excited to share that I'll be speaking at React Day Berlin 2026 this December! My talk How I Brought React Into a Preact Form Engine: A Production Bridge Pattern I'll walk through how we integrated React into an existing Preact-based form engine in production — the bridge pattern we used, the trade-offs, and what I'd do differently next time. Duration: up to 20 minutes Dates: December 4 & 7, 2026 Format: remote or in-person (TBD) Join me (free stream access) You can register through my speaker badge and get partial free access to watch the stream: 👉 My React Day Berlin 2026 badge Speaker page: reactday.berlin/#person-sam-abaasi ReactDayBerlin #react #preact #javascript #webdev See you there!

Hoi hoi! I'm @nyaomaru, a frontend engineer. Thanks to my daily Duolingo streak, Dutch is finally...

After five years of shipping features at Tittri, the team gave me a piece of feedback that stung a little: I was good, but I only ever built what I was asked to build. And we delivered, end to end, every week. From dashboards to multi-step workflows to third party integrations, all of it to make dense workflows understandable. Somewhere along the way I'd become all about business critical web apps, where the frontend is not just visual, it's how people execute operations reliably. But it just wasn't enough for me. So in January 2026 I stopped waiting to be asked, and pitched an AI integration into a UK-based fintech client's product, one that handles real business loans. When I finally presented the idea to the team and the client, after enough brainstorming and planning and identifying the best way for the brokers to benefit from it, expectations rose. No prior AI integration experience, no matching tutorials, real users, real data, real money. Then I had to actually build it. What is the client and why AI The client is one of the UK's pre-eminent business finance brokers and comparison services that combines advanced technology with a team of finance experts to help small and medium-sized enterprises (SMEs) and their advisors find, compare, and apply for the most appropriate and affordable funding options from across the entire market. The client's B2B product is a commercial finance brokerage SaaS, where brokers manage deals, calls, emails, documents, lenders, AIPs (Agreement In Principle), credit/KYC, corporate structures, properties...etc. The brokers use the SaaS to run the whole lifecycle of a deal, and before AI every single step of it was manual. A typical deal goes like this: An enquiry comes in by call or email, something like "my client needs £400k to buy out a GP partner". The broker gets on a discovery call that can run 30–90 minutes, writes up the notes afterwards, creates the deal, and then starts gathering everything a lender will want to see. Finan

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. I originally...

That 130-file PR that shipped KeyEcho 1.0 contained a decision I never wrote about: the desktop app moved from Tauri 1 + Vue to Tauri 2 + SolidJS. The same summer, upweb.dev moved from Nuxt 4 to SolidStart, and keyecho.app (SSR, five languages, Stripe checkout) was built on SolidStart from scratch. Three separate decisions, same answer every time. Scope first. This post is about defaults for my personal projects. Near the end I'll cover two places where I still use React, one of which runs very well. The criteria changed Most of the code in my repos is AI-generated now. My job has shifted from writing code to reviewing it. The old framework checklist put most of its weight on learning curve and developer experience. Both are worth zero now: the model writes five frameworks fluently and knows the rules of hooks better than most humans do. AI crushed the price of writing code. Two costs didn't move: the runtime bytes every user downloads, and the human hours spent reviewing. Pick your stack by the new prices. Runtime cost lives in the architecture. No prompt removes it, so it decides the framework. Review bandwidth is finite, and AI throughput will grind down any consistency that is maintained by verbal agreement, so it decides the styling layer. I have seen more than one React codebase a few years into its life: two animation libraries, two carousel components, three styling systems, each introduced for a perfectly good reason on some ticket, and the sum is a mess nobody can clean up. AI did not invent that drift. It made it an order of magnitude faster. React is no longer my default: size and performance Let me discard the weak arguments first. Dependency arrays, stale closures, re-render storms: I am not going to relitigate any of it. The model knows the rules of hooks cold, eslint-plugin-react-hooks catches most slips, and React Compiler now handles memoization. The ergonomics debate no longer produces a winner. What still produces a winner is the client. react-do

Liquid syntax error: Variable '{{% raw %}' was not properly terminated with regexp: /\}\}/

Streaming LLM responses in TypeScript: SSE, ReadableStream, and the React 19 useChat hook. The first time I wired an LLM response that streamed token by token instead of arriving as one lump after 4 seconds, I shipped it to production the same afternoon. The difference in perceived speed is that obvious to anyone who has used ChatGPT and then tried a non-streaming competitor. Users will wait 8 seconds if they can see the cursor moving. They will not wait 4 seconds for a blank screen. This tutorial walks the full stack from scratch. By the end you have a working Next.js API route that streams from an LLM over Server-Sent Events, a frontend that parses the stream manually with ReadableStream , and then the same UI rebuilt with the Vercel AI SDK's useChat hook so you can see what the abstraction actually buys you. TL;DR Layer What you build Key API Next.js route Streams LLM output as SSE streamText + toUIMessageStreamResponse Vanilla client Parses the stream by hand ReadableStream , TextDecoderStream React 19 client Managed state + cancellation useChat from ai/react Edge cases Backpressure, cancel, tool chunks AbortController , partial JSON guard 1. Why streaming matters A standard fetch returns after the entire response body is ready. For short completions, that is fine. For anything over 100 tokens, users see a spinner, then a wall of text, then confusion about whether the app is fast or slow. Streaming changes the shape of that experience. The first token lands in under 300ms for most hosted models. The user starts reading while the model is still writing. Perceived latency drops by 60 to 70 percent even if the total time to complete the response does not change. Cost transparency is the second reason to care. When you stream, you count tokens as they arrive. If your route has a budget ceiling and the response is going to blow past it, you can cut the stream at 800 tokens without ever waiting for the full completion. That cut is not possible with a blocking call. 2.

Originally published on the MyTreda engineering blog: read here A support message described what looked like one confusing mobile bug. It turned out to be two independent ones — a cross-site cookie getting blocked by Safari's ITP, and a React Hook Form autofill desync — that just happened to both only show up on mobile. Full breakdown, code, and fixes below.

Installation traceless-style is published to npm. It has no required dependencies at runtime and one optional dependency ( @swc/core ) that the SWC-backed extractor uses for large codebases. 1. Install the package npm install traceless-style # or pnpm add traceless-style # or yarn add traceless-style The package ships pre-built. There is no postinstall step. Peer dependency Required? What for react ≥ 18 Optional Only needed for the React components in traceless-style/dark and traceless-style/rtl ( <TracelessRoot /> , <ThemeToggle /> , <RtlToggle /> ). next ≥ 14 Optional Only needed if you use traceless-style/nextjs . webpack ≥ 5 Optional Only needed if you wire up the raw webpack plugin. vite Optional Only needed for traceless-style/vite . @swc/core Optional Auto-loaded for projects ≥ 100 source files. Falls back to the legacy parser if installation failed. 2. Pick an integration You're using… Install one of Next.js (App Router or Pages) traceless-style/nextjs Webpack directly (CRA-style or Rspack) traceless-style/webpack Vite traceless-style/vite Rollup traceless-style/rollup esbuild traceless-style/esbuild Just Node + a build script The CLI: npx traceless-style Each integration page contains a copy-paste config snippet. 3. Run init (recommended) npx traceless-style init This zero-config scaffolder: Detects your framework (Next, Vite, Remix, Astro). Adds the bundler plugin to your config file. Adds <TracelessRoot /> to your root layout (anti-flash dark + RTL script). Creates traceless-style.config.js if missing. Adds dev / build scripts to package.json if missing. Suggests installing the VS Code extension via .vscode/extensions.json . The scaffolder is idempotent — re-running it will not duplicate edits. 4. Verify the install Create a tiny component: // app/test-install.tsx import { tl } from " traceless-style " ; const $ = tl . create ({ hello : { color : " tomato " , padding : " 1rem " , fontSize : " 1.25rem " }, }); export default function Test () { return < div

Over the weekend, I participated in the OpenAI Build Week Hackathon with a simple goal: Build something I would actually use as a developer. By Friday evening, I had an idea. By Sunday, that idea became an open source project called Arcovia . It wasn't just another AI coding experiment. I wanted to solve a problem I've faced while working on large React applications for years. The Problem We have excellent tools for code quality. ESLint catches code smells. Prettier formats code. SonarQube reports issues. AI reviews code and suggests improvements. But none of them answer questions like: Is my architecture healthy? Which modules are becoming bottlenecks? Where is technical debt accumulating? Which files should I refactor first? Why did my project receive this score? Architecture is often something we discuss during code reviews or realize too late when the codebase becomes difficult to maintain. I wanted a tool that could measure architecture health before it became a problem. Introducing Arcovia Arcovia is an Architecture Intelligence tool for React and Next.js projects. Instead of generating hundreds of isolated warnings, it analyzes the project as a whole and produces an interactive HTML report. It includes: 📊 Architecture Health Score 🕸️ Dependency Graph 🎯 Architecture Hotspots 📈 Explainable Score Breakdown 🛠️ Rule-based Findings 📉 Maintenance Burden ✅ Actionable Recommendations The goal isn't to replace linting. The goal is to help developers understand the bigger picture. How It Works Internally, Arcovia follows a deterministic analysis pipeline. Project │ ▼ Scanner │ ▼ AST Parser │ ▼ Project Model │ ▼ Dependency Graph │ ▼ Rule Engine │ ▼ Score Engine │ ▼ Interactive HTML Report The analyzer currently detects things like: God Modules High Fan-In High Fan-Out Orphan Modules Large Components Deep JSX Nesting Oversized Modules Duplicate Imports Unused Exports Instead of simply reporting findings, Arcovia combines them into an explainable architecture score. Determ

TypeScript Generic Constraints in Depth: extends , keyof , and the Patterns That Prevent Runtime Errors This article was written with the assistance of AI, under human supervision and review. Most TypeScript runtime errors stem from unconstrained generics that accept anything and crash on nothing. Teams write function get<T>(obj: T, key: string) and ship code that compiles cleanly but throws Cannot read property 'undefined' of undefined in production. The compiler stays silent because the generic accepts any type and the key accepts any string—no constraint exists to prove the key belongs to the object. Generic constraints solve this by restricting what types a generic parameter can accept. The extends keyword establishes a boundary—the generic must satisfy a specific shape. The keyof operator extracts valid keys from that shape. Together they form a type-level contract that makes illegal property access unrepresentable. The corrected signature function get<T, K extends keyof T>(obj: T, key: K): T[K] proves at compile time that key exists on obj , eliminating the entire class of property-access errors. This distinction is critical. Unconstrained generics provide no safety beyond what any offers. Constrained generics encode domain rules directly into the type system, shifting entire categories of bugs left from runtime to compile time. The patterns that follow demonstrate how production codebases use extends and keyof to build type-safe APIs that fail fast during development instead of silently in production. Key Takeaways Generic constraints with extends restrict type parameters to specific shapes, preventing the compiler from accepting types that would cause runtime failures. The keyof operator extracts object keys as a union type, enabling type-safe property access when combined with extends keyof constraints. Combining T extends SomeType with K extends keyof T creates a compile-time proof that a key exists on an object, eliminating property-access errors. Conditi

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . There is a version of this story where I walk you through the technical challenges in a clean, detached voice. Structured. Professional. Composed. This is not that version. Seven months. A hundred pages of documentation written alongside the code, not after it. A live system serving rural clinics in Delta State, Nigeria. And three bugs so specific and so cruel that each one felt designed to find the exact gap between what I thought I knew and what I actually knew. The Delta Health Information and Appointment Booking System was my final year project at the University of Port Harcourt. That sentence makes it sound smaller than it was. This was a real system for real clinics, serving patients who travel for hours to reach a healthcare facility only to find the clinic is full, the doctor is not in, or nobody told them their appointment was cancelled. These are not hypothetical users. These are people whose access to healthcare depends on whether the software works. That is a different kind of pressure than getting a good grade. And it did not start at deployment. Before a single line of code was written, I had to pitch the entire concept to my university supervisor, the Head of Department, the Faculty Dean, and an external examiner. The system had to be defensible not just technically but practically. It had to demonstrate that it solved a real problem that real people in Delta State were actually facing. I was presenting to people with decades of experience who would ask questions I had not thought of yet. That kind of scrutiny either sharpens you or breaks you. I chose to let it sharpen me. The stack was React.js, Node.js, PHP with Laravel, MySQL, AWS, and Docker. Communication channels included SMS gateways, WhatsApp Business API, and USSD because not every patient in rural Delta State has a smartphone. The system had to run on 2G connections, on entry-level Android phones with 2GB RAM

Before I critique modern web development, I want to make some points: I'm not discouraging anybody from web development. This is only my opinion and my experience of the story. Everyone has their own story. Part 1. Javascript JavaScript is known for being the web's language. It's used everywhere in the web, and can also be used to make external applications outside of web development. JavaScript has many flaws in its language, such as its comparison logic. JavaScript uses the "strict equality operator" that tries to solve its weird type coercions (e.g [] == ![] being true). Another flaw is that JavaScript has poor maintainability. JavaScript has a poorly managed type system that introduces errors without proper error handling. You cannot explicitly define what error you're trying to catch in the try-catch statement. try { functionThatThrowsError () } catch ( error ) { console . error ( error ); if ( error instanceof MyError ) { doSomething (); } } instead of modern languages: try { functionThatThrowsError () } catch ( e : MyError ) { print ! ( " error: ${e.message} " ) } This adds complexity to try-catch statements and makes it almost impossible to handle errors in a robust manner. Another issue with JavaScript's maintainability is the wording of the language. JavaScript has two keywords called undefined and null . In practice these should mean the same thing but it doesn't. An undefined variable is an uninitialized variable, or a function that doesn't return anything. Undefined: // Returns undefined function getName () {} // syntactically correct in JavaScript // but will cause undefined console . log ( getName ()); const myCoolObject = {}; console . log ( myCoolObject . property ); // still syntactically correct in JavaScript even though the property doesn't exist. Null: // Returns a null name function getName () { return null ; } // output: null console . log ( getName ()); const myCoolObject = { property : null }; console . log ( myCoolObject . property ); //out