Your Bundle Is a Beast, and It’s Biting Your Users

Performance isn’t a maybe. It’s the thing that decides whether someone sticks around or bails after three seconds on a spotty 3G connection. I’ve watched too many React apps deploy with bloated bundles—huge monolithic chunks that drag load times straight into the gutter. The kicker? Developers think they need all that code. They don’t. You can shave off kilobytes without dropping a single feature. This isn’t some trick. It’s about being stubborn, using the right tools, and refusing to let dead code squat in your production build.

Start With a Knife: Audit Before You Optimize

Guessing is a waste of time. Before you mess with a single import, get a visual map of your bundle. Tools like source-map-explorer or webpack-bundle-analyzer show you exactly which modules are the space hogs. I once caught a date-picker library eating 40% of a client’s main chunk—a library we used in exactly one component. That’s the kind of leak you’ll never spot just by staring at the code.

Configure Your Analyzer for Real Data

Run the analyzer against your production build, not development. Dev mode throws in hot reloading and unminified sources that mess with the picture. For Webpack, add a script like this:

"analyze": "source-map-explorer 'build/static/js/*.js'"

Open the HTML report and hunt for heavy paths—node_modules folders are almost always the villains. Make a list: What’s fat? What’s duplicated? What’s imported but never actually rendered? This triage step alone can hand you some quick wins.

Tree Shaking: More Than a Buzzword

Tree shaking is meant to ditch unused exports. But it fails quietly if you don’t set things up right. ES modules (import/export) are non-negotiable; CommonJS (require) kills tree shaking because it’s dynamic by nature. Check your package.json dependencies. If a library only ships a CommonJS build, you’re dragging in the whole thing.

Side Effects: The Hidden Killer

Webpack’s tree shaking leans on the "sideEffects" flag in a library’s package.json. If a package doesn’t declare this, or sets it to true, Webpack assumes every file might mess with globals and keeps everything. You can override this in your own config by marking specific files as side-effect-free. For instance:

module.rules: [{
  test: /\.js$/,
  sideEffects: false
}]

Be precise here. Marking a CSS file as side-effect-free will wreck your styles. Test it hard.

Code Splitting: Serve Only What’s Needed, When It’s Needed

Your landing page doesn’t need the admin dashboard’s chart library. Route-based splitting is the bare minimum. With React’s lazy and Suspense, you can push entire page components off until the user actually goes there:

const Dashboard = React.lazy(() => import('./Dashboard'));

A single split point can slash initial load by hundreds of kilobytes. But don’t stop at routes. Split below the route level—heavy modals, complex form wizards, video players. If a component isn’t visible on that first render, it’s a candidate for lazy.

Named Chunks and Prefetching

Use webpack magic comments to name chunks and control loading priority. For a search modal users might trigger, prefetch it so it’s ready when they click:

const SearchModal = lazy(() => import(
  /* webpackChunkName: "search" */
  /* webpackPrefetch: true */
  './SearchModal'
));

Prefetching grabs the chunk during browser idle time. It’s a tightrope—don’t prefetch everything, or you’ll ruin the whole point. Save it for interactions with a high probability.

Dependency Detox: Replace, Don’t Just Trim

Some libraries were built for a different time. Moment.js is 230KB+ unminified, and you probably use 5% of its API. Swap it for date-fns or dayjs, which are modular and tree-shakeable. Lodash? Import only the functions you need: import debounce from 'lodash/debounce' rather than import _ from 'lodash'. Even better, lean on native methods when you can. Array.prototype.find doesn’t need a polyfill in 2024.

Visual Components: Look Hard at What You Import

Material UI, Ant Design, and similar kits are handy, but their default imports often drag in entire icon sets and theme engines. Use path imports exactly how the docs tell you. For MUI v5, import Button from '@mui/material/Button' works, but you’ll need a Babel plugin or serious self-discipline. For icons, import individual SVGs—@mui/icons-material/Delete—never the top-level barrel file.

Compression and Modern Bundles: The Browser Can Handle More Than You Think

Gzip and Brotli compression on your server can shrink text assets by 70% or more. That’s a one-line config change in Nginx or your CDN. But you can also serve differential bundles: modern ES2017+ code for newer browsers, and a heavier legacy fallback for IE11 if you absolutely must support it. The module/nomodule pattern is a battle-tested way to deliver smaller files to 90%+ of users. Tools like Vite handle this right out of the gate, but you can configure Webpack with browserslist and multiple output targets.

Lazy Load Everything That’s Below the Fold

Images, iframes, and third-party scripts are the quiet partners of bundle bloat. An unoptimized hero image can hit 2MB, and a chat widget can lock the main thread for seconds. Use loading="lazy" on images and iframes. For React components, use Intersection Observer to conditionally render heavy sections only when they scroll into view. Libraries like react-lazyload make this a breeze, but a 10-line custom hook is even lighter.

Fonts and Icons: Self-Host and Subset

Google Fonts loads from an external domain and often ships entire character sets. Self-host your fonts and subset them to the characters you actually use—Latin, maybe Cyrillic if your audience demands it. Tools like glyphhanger automate this. For icons, inline SVGs as components instead of loading a whole icon font. A single SVG is a few bytes; an icon font is often 100KB+ for a handful of used glyphs.

Measure the Impact, Not the Effort

After each change, re-run your bundle analyzer. Track numbers: initial JavaScript kilobytes, time-to-interactive, Lighthouse performance score. Share these with your team. When you replace Moment with Dayjs and see a 200KB drop, that’s a win you can name. Optimization isn’t a one-and-done project. It’s a habit you bake into pull request reviews. If a dependency adds more than 20KB, make it justify itself.

Frequently Asked Questions

Why did my bundle size increase after adding tree shaking?

Real tree shaking removes unused code, so a bump usually means something else shifted. Maybe you dropped in a new dependency, or your side-effect declarations are too wide, blocking removal. Check your analyzer diff between builds. Also, some libraries bundle development warnings that only get stripped in production mode. Make sure you’re comparing production builds.

Does code splitting slow down navigation?

It tacks on a small network request the first time a user hits a split chunk, but the trade-off is a much zippier initial load. With prefetching or preloading, you can make the transition feel near-instant. The trick is to keep chunk sizes sensible—around 50-100KB per chunk—so the download is fast even on sluggish connections.

What’s a realistic bundle size target for a React app?

No one number fits all, but aim for under 200KB of initial JavaScript (minified and compressed) for a typical marketing or content site. For data-heavy dashboards, under 500KB is fair if the core interactivity needs it. The real measure is Time to Interactive under 3 seconds on a median mobile device. Use WebPageTest or Lighthouse to check.

Can I use dynamic imports without React.lazy?

You bet. React.lazy is just syntactic sugar for dynamic imports that return a component. For libraries or utilities, you can use a plain import() call in an event handler or lifecycle method. For example, load a PDF generation library only when the user clicks “Export”: handleExport = async () => { const pdfLib = await import('pdf-lib'); ... }. This keeps chunky utilities out of the main bundle.

For years, React devs have been stuck in the same tired data-fetching loop. You fire off a request from the client, watch a spinner twirl, and eventually—maybe—render some data. Then you bolt on a state management lib to cache the response, a routing layer to pre-fetch, and a handful of useEffect hooks that kick off network calls. React Server Components (RSC) don’t just tweak this model—they bin the whole mental framework. If you’re still thinking in terms of client-side waterfalls, you’re already behind.

The Waterfall Problem Nobody Solved

Traditional React apps suffer from a network waterfall baked straight into the component tree. A parent fetches user data, a child uses that user ID to grab orders, and a grandchild pulls order details. Each step waits for the one before it. You can patch things up with parallel requests or a GraphQL layer that aggregates queries, but the client still calls the shots. The browser sends a request, parses the response, paints a little UI, then triggers the next fetch. That round-trip lag piles up fast, especially on spotty mobile connections.

The real sting isn’t just speed—it’s the complexity. Devs scatter data-fetching logic across components, wrappers, and middleware. One page might touch a REST endpoint, a GraphQL query, and a third-party API, all stitched together with Redux or React Query. Debugging this tangle means tracing client-side state, server logs, and network tabs at the same time. RSC sidesteps the whole mess by shifting the data-fetching phase to the server, where it runs once per request with zero client-side choreography.

How Server Components Actually Work

React Server Components live and die on the server. They never ship JavaScript to the browser. Instead, they render to a special format React can stream and hydrate on the client. When a user hits a page, the server runs the RSC tree, grabs all the data it needs—from databases, APIs, file systems—and sends the serialized result. The client gets a pre-built UI with data already tucked inside, skipping the usual fetch-then-render dance entirely.

This flips the default: data fetching becomes a server problem. You write components that look like regular React, but you can use async/await right at the top level. No useEffect, no loading states, no client-side caches. A component can read from a database or call an internal service without exposing API endpoints to the browser. The framework (Next.js, for example) handles streaming and suspense boundaries so the page loads in chunks as data resolves.

Zero-Bundle Components

A Server Component’s code stays put on the server. The client never downloads, parses, or executes it. That means you can import hefty libraries—a markdown parser, a date utility, an ORM—without ballooning the client bundle. The component chews through data on the server and sends only the rendered output. Take a blog page that formats posts with syntax highlighting: you can use a chunky library like Prism or Shiki and the user’s device never feels it. The client receives static HTML with highlighted code already in place.

This rewrites the trade-off around third-party dependencies. You no longer have to pick between a feature and its bundle weight. Use whatever library gets the job done on the server, and keep the client lean. The payoff is faster page loads and less JavaScript to crunch, which matters most on underpowered devices.

The Real Performance Shift

Performance gains from RSC aren’t just about that first paint—they’re about removing whole categories of work. With client-side fetching, the browser has to download, parse, and execute JavaScript before it can even ask for data. Then it waits on the network, processes the response, and updates the DOM. RSC collapses that sequence: the server does the heavy lifting while the client streams HTML. Time to first byte might tick up a bit because the server is busier, but time to interactive drops hard because the client has way less to do.

Picture an e-commerce product page. Without RSC, the client loads a shell, fetches product data from an API, then fetches reviews, then fetches related items. With RSC, the server queries all three sources at once, pieces the page together, and streams it. The user sees the product image and title almost instantly, while reviews and recommendations trickle in as they arrive. No spinners, no janky layout shifts from deferred data—just a page that feels solid from the first frame.

Security Through Server Isolation

When data fetching lives on the client, you expose API endpoints anyone can prod. Even with auth, the client sees the raw data shape. A nosy user can crack open the network tab and eyeball the full JSON response, including fields you might not even render. With RSC, the server queries the database directly and sends only the rendered output. Touchy logic—permission checks, proprietary algorithms—stays on the server. You can query internal services without spinning up public endpoints, which shrinks the attack surface.

This also takes the edge off compliance. Data that should never graze a user’s device—PII, financial records—lives on the server by default. The client gets a visual representation, not the raw data itself. For teams juggling HIPAA, GDPR, or PCI-DSS, this is a practical way to cut scope without piling on extra infrastructure.

Rethinking Component Architecture

RSC forces you to split components by their runtime, not just their visual gig. Server Components own data fetching and heavy computation. Client Components own interactivity—event listeners, state, effects. The boundary between them becomes explicit. You tag a file with ‘use client’ at the top to mark it for the browser; everything else defaults to the server. This directive flips the old model where everything was client-first.

This separation nudges you toward a natural pattern: Server Components fetch and shape data, then pass it as props to Client Components. The client pieces become mostly presentational, focused on rendering and reacting to input. Say you have a search page. A Server Component queries the database for initial results, then a Client Component handles the search box and live filtering. The server tackles the heavy query; the client manages the interactive bits.

When Client Components Still Matter

Not everything belongs on the server. If a component touches browser APIs—window, document, Web APIs—it has to run on the client. That covers most form libraries, animation tools, and real-time subscriptions. The trick is to keep these components as small as possible. A common blunder is wrapping a whole page in ‘use client’ because a tiny section needs a click handler. Instead, yank that interactive piece into its own Client Component and leave the surrounding layout on the server.

This approach also sharpens code splitting. Client Components are the only bits that add to the JavaScript bundle. By trimming them down to the bare minimum, you slash how much code the browser has to download and parse. The server-rendered parts stream as HTML with zero JavaScript baggage.

Practical Migration Steps

Moving an existing app to RSC isn’t a rewrite—it’s a slow, deliberate shift. Start by spotting components that fetch data but have no interactivity. Move those to the server, one at a time. Swap client-side fetch calls for direct database queries or server-side API calls. Strip out loading states and error boundaries that were handling client-side network hiccups; the server can deal with errors before anything hits the client.

Next, audit your dependencies. Libraries that only transform data—date formatters, markdown parsers, validation tools—can shift to the server. Anything that needs the DOM stays on the client. This audit often shows that a startling amount of code can leave the bundle entirely. One team I worked with lopped 40% off their client JavaScript just by moving data-fetching logic to Server Components.

Streaming and Suspense

RSC hooks into React’s Suspense to stream content as it’s ready. Wrap a Server Component in a Suspense boundary, toss in a fallback, and React sends the fallback first while the server finishes the component. Once the data resolves, React streams the updated HTML and swaps out the fallback. This kicks in without any client-side JavaScript for the initial load. The browser gets a stream of HTML chunks and progressively paints them.

This warps how users perceive speed. Instead of staring at a blank page while everything loads, they see the shell right away and content fills in. It’s not a spinner; it’s actual content arriving in pieces. For a dashboard pulling from several data sources, you can stream each widget independently, so the fastest queries surface first.

Frequently Asked Questions

Do React Server Components work without a framework?

Technically, yes, but it’s not practical. RSC needs a server runtime that can render React components and stream the output. Frameworks like Next.js serve that up out of the box. Building it from scratch means cooking up a custom server, a bundler that splits server and client code, and a streaming protocol. For most teams, leaning on a framework is the only sensible move.

Can I still use client-side data fetching libraries like React Query?

You can, but you’ll use them differently. React Query still earns its keep for Client Components that fetch data off the back of user interaction—like a search-as-you-type input or infinite scroll. The big difference: initial page data no longer depends on it. Server Components handle the first paint; React Query deals with later client-side updates. This shrinks the library’s scope and often simplifies its setup.

How does authentication work with Server Components?

Auth happens on the server, usually through cookies or headers piggybacking on the request. The server component reads the session, checks it, and fetches user-specific data—all before any HTML reaches the client. The client never glimpses the auth token or the raw user data. This pattern sidesteps the common trap of stashing tokens in localStorage and cuts the risk of XSS attacks spilling sensitive info.

What about SEO and search engine crawlers?

RSC gives SEO a boost by default. Since the server renders full HTML with all content, crawlers see a complete page without needing to execute JavaScript. It’s a swing back to server-rendered roots but with React’s component model along for the ride. Dynamic data—product listings, blog posts—sits right in the initial HTML response, so it’s indexable straight away.

React Server Components aren’t an incremental tweak—they’re a hard reset on where your code runs and who foots the bill. The server handles data; the client handles pixels. If you’re still designing components around useEffect and fetch calls, you’re tuning up a model that’s already scrap.

Where We Are with State in 2026

React state management finally grew up. The old Redux boilerplate and those sprawling useEffect chains are mostly dead in serious codebases. What’s taken their place is a fairly quiet, practical consensus around a few patterns that don’t buckle when your app gets big. Nobody’s arguing about which library is best anymore. The real question is where you put the state and why you put it there. In 2026, solid React teams treat state like a design constraint, not a shopping trip for tools.

I’m Suki Watanabe. I’ve spent the last few years pulling apart state logic in production systems—fintech dashboards, real-time collaboration canvases, content-heavy consumer apps. The patterns here are the ones I reach for first. No fluff. No ceremony. Just what ships and stays shipped.

Pattern 1: Server State Stays on the Server

Most teams can recite the difference between server state and client state by now. Actually sticking the landing? That still slips. In 2026, the pattern that keeps things sane is treat the server as the source of truth, and treat the cache as a replica. TanStack Query (what we used to call React Query) and SWR both handle this well, but the pattern is bigger than any single library.

The rule in practice: if the data came from an API, don’t copy it into useState or a global store. Let the fetching library own the lifecycle—stale-time policies, background refetching, optimistic mutations. For a dashboard pulling portfolio data, I stick to one useQuery call per entity, pull the UI state right off the cache, and let the library revalidate on window focus or network reconnect. The component tree stays skinny, and I dodge the “dual source of truth” bugs that hand-rolled stores breed.

Here’s the shape it takes, concretely:

// Instead of useState + useEffect + global store:
function Portfolio({ userId }) {
  const { data, isLoading, error } = useQuery({
    queryKey: ['portfolio', userId],
    queryFn: () => fetchPortfolio(userId),
    staleTime: 5 * 60 * 1000,
  });

  if (isLoading) return <Skeleton />;
  if (error) return <ErrorBanner />;
  return <PortfolioChart data={data} />;
}

The decision that really matters here is staleTime. For fast-moving data like live pricing, I drop it to zero but keep the cache as a fallback. For user profiles, I set it to Infinity and manually invalidate on profile updates. The pattern scales because the cache becomes the single layer between the component and the network—no duplication, no drift.

Pattern 2: Colocate Client State, Then Lift It Only When You Must

Client state—form inputs, modal visibility, the selected tab—has the opposite rule: keep it as close to the consumer as you can. By 2026, the React world has mostly quit dumping UI state into global stores because, well, that’s what everyone did five years ago. The payoff is components that are easier to test and a lot easier to delete.

Start with useState inside the leaf component. If a sibling needs access, lift the state to the nearest common parent. Only grab context or a tiny Zustand slice when the consumer tree is deep or spread all over the place. I’ve walked into too many codebases where a Redux store carries an `isModalOpen` boolean that exactly one component and its direct child care about. That’s a tax you pay on every render and every refactor.

For shared UI state that actually needs to cross routes or worm through deeply nested trees, I use React Context with a small reducer, or a single Zustand store split into slices. The hard constraint: the store holds only serializable, UI-specific values. Business entities stay in the server cache. A real example from a multi-step onboarding flow: a Zustand slice holds the current step index, a draft object for form fields, and an `isSubmitting` flag. Everything else—validated data, available options—comes from TanStack Query. The boundary is clean, and the store is under 40 lines.

Pattern 3: Derived State Shouldn’t Be Stored

One of the sharpest cuts you can make in a React codebase is stripping out stored derived values. If you can compute a piece of data from existing state, compute it at render time—with useMemo when the computation is heavy—and never write it to state. In 2026, this is table stakes, but I still audit codebases where someone stored `fullName` separately from `firstName` and `lastName`.

The pattern I enforce: every piece of state in a component or store must be a source, not a result. For a shopping cart, the stored state is an array of item IDs and quantities. Total price, item count, discount eligibility—those are derived in a useMemo or, better, in a pure function outside the component that takes the cart array as input. This wipes out an entire class of synchronization bugs and makes the code easier to reason about immediately.

When the derivation gets expensive, I lean on useMemo with a clear dependency array. But I also trust the React compiler work that’s landed by 2026: automatic memoization is real in many setups, and I don’t scatter useMemo around defensively anymore. The pattern is to write clean, pure derivations and let the runtime do its job.

Pattern 4: URL State Is a First-Class Store

In 2026, the URL bar is the most underrated state container in React. For any state that should survive a refresh, be shareable, or drive server data fetching—put it in the URL. Search filters, pagination offsets, selected item IDs: these belong in query parameters or path segments, not in a Redux store or a context that evaporates on navigation.

The tooling here is solid. React Router v7 (or whichever routing library you’re on) makes it simple to read and write URL search params with hooks like `useSearchParams`. On a recent product catalog rebuild, I moved all filter state—category, price range, sort order—into the URL. The component tree reads the params on mount, plugs them into the server state query key, and updates the URL on user interaction via `setSearchParams`. The result: deep-linkable pages, zero client-side state for filters, and a back button that actually works.

The pattern pairs cleanly with server state management. The query key for TanStack Query becomes `[‘products’, searchParams.toString()]`, and the library handles data fetching off URL changes. When the user hits back, the URL changes, the query refires (or serves from cache), and the UI updates—no synchronization code needed.

Pattern 5: Immutable Updates with a Light Touch

Immutability isn’t a library choice in 2026; it’s a language habit. With the spread operator, optional chaining, and tools like Immer around, the pattern is: never mutate state in place, but don’t over-engineer it. In most production code I write, I use plain JavaScript spread for shallow updates and reach for Immer only when the state shape is deeply nested and the update logic would turn into a mess with spread alone.

For a complex form with nested sections, Immer’s `produce` function lets me write what looks like mutation while keeping the state tree intact. But I keep its use localized—a reducer inside a single component or a small Zustand slice. The wider application never needs to know Immer exists. That keeps the bundle impact low and the mental model simple.

The real pattern here is discipline: if you see a direct assignment like `state.items[3].name = ‘new’`, fix it right now. The cost of that bug in concurrent rendering and strict mode is too high to ignore.

Choosing Your Tools: A Quick 2026 Map

The libraries have settled into clear roles. Here’s the lineup I recommend based on what’s held up in production:

• Server state: TanStack Query v6. Mature, well-documented, handles caching, pagination, and optimistic updates out of the box.
• Client state (small to medium): React Context + useReducer. Zero dependencies, great for theme, auth status, or a small wizard flow. Keep the value stable with useMemo to avoid unnecessary renders.
• Client state (larger or cross-route): Zustand v5. Minimal API, no providers, supports slices and middleware like `persist` for localStorage. My default for anything that outgrows Context.
• Form state: React Hook Form with Zod validation. Handles complex fields, arrays, and validation schemas without re-rendering the whole form on every keystroke.
• URL state: React Router’s `useSearchParams` and `useParams`. No extra library needed.

Notice what’s missing: Redux, MobX, Recoil. They all still work, but the combination above covers 95% of use cases with less ceremony. If you’re on a legacy Redux codebase, the migration path is to carve out server state into TanStack Query first, then move UI slices to Zustand or Context piece by piece.

FAQ

When should I use a global store instead of React Context?

Use a global store (like Zustand) when the state needs to be accessed by many unrelated components across different parts of the tree, and when performance matters—Context can cause widespread re-renders if the value changes frequently. If the state is consumed by a single subtree and changes rarely (e.g., theme), Context is fine.

Is it okay to mix server state and client state in the same store?

No. This is a common source of bugs. Server state has a lifecycle (loading, error, stale) that client state doesn’t. Keep them separate: server data stays in TanStack Query or SWR, client UI state stays in a small store or local useState. If you need to combine them, do it in a hook that reads from both sources and derives the final shape.

How many state management libraries should a mid-size app use?

Two, maybe three: one for server state (TanStack Query), one for client state (Zustand or Context), and possibly a form library (React Hook Form). Adding more than that usually means you’re solving organizational problems with tools, or you’ve inherited a legacy stack you’re actively shrinking.

What’s the best way to handle optimistic updates in 2026?

TanStack Query’s `onMutate` callback is still the cleanest pattern. You snapshot the current cache, apply the expected change immediately, and roll back on error. Keep the optimistic update function pure and close to the mutation definition so the logic is easy to audit. Skip optimistic updates for operations that fail often or have complex side effects—the flicker isn’t worth it.

State management in React has finally become boring, and that’s a good thing. The patterns above aren’t flashy, but they’ve kept my teams moving fast and shipping with confidence. Start with server state, colocate the rest, compute what you can, and let the URL do the heavy lifting. The rest is details.

React doesn’t hand you a single way to manage state. That’s part of the charm, and also why the conversation never really ends. But 2026 is different. We aren’t fighting the hooks-vs-Redux war anymore. The hard questions now are more practical: how do you stop server state and UI state from leaking into each other? When does a plain useReducer beat dragging in a store? And what patterns actually survive a 50 KB bundle budget and a remote team spread across three time zones?

Over the past year I’ve refactored three mid-sized React apps that had turned into state spaghetti. The patterns that work right now aren’t the ones from 2020 blog posts. They’re leaner, more composable, and honestly, kind of boring—in the best way. Here’s what I reach for today.

Server State vs. UI State: Draw the Line or Suffer

Where you split data that lives on the server from data that only exists in the browser is the single biggest call you’ll make in a React app. Get it fuzzy and every feature costs twice as much to debug. By 2026, the community has mostly settled on a clean cut: server state goes to a dedicated cache like TanStack Query or SWR; UI state stays inside React or a tiny external store.

The rule I enforce on every project: if the data comes from a fetch call, it never, ever touches useState or a global store. TanStack Query owns the fetch, the cache, the retries, the staleness. You consume it through useQuery and your component re-renders only when the cache actually flips. This isn’t a performance hack—it’s a correctness guarantee. Roll your own useEffect with a manual cache and refetch flags and I promise you’ll ship duplicate requests or stale data eventually. I’ve seen it in every codebase that tried to be clever.

The side effect? Your global store shrinks to almost nothing. I’ve deleted whole Redux slices that were just a badly cached API response dressed up in boilerplate. Zulip’s frontend team wrote about a similar move away from custom fetch layers toward TanStack Query—hundreds of lines of boilerplate gone, and race conditions that had been lurking for years finally squashed.

Zustand Over Context for Anything Shared

React Context is not a state management tool. It’s a dependency injection mechanism. Stick a value that changes often into context and every consumer under that provider re-renders, even the ones that don’t read the value. In 2019 we could plead ignorance. In 2026, we just look negligent.

For shared UI state—sidebar open, theme, the active modal ID—I grab Zustand. The API is tiny; you can learn it while your coffee cools. A store is just an object with a set function. You subscribe with a selector, and Zustand only triggers a re-render when that specific slice changes. No providers, no context wrapping, no React.memo incantations.

A habit I’ve leaned into harder this year: colocating Zustand stores with features. Instead of one monolithic store, I create a feature/dashboard/store.ts that exports a useDashboardStore hook. That store owns panel visibility, selected widget IDs, drag state. Nothing else in the app knows it exists. When the dashboard feature gets the axe, the store vanishes with it. No global state archaeology required.

URL as the Source of Truth for Page State

I still see teams stuffing search query strings and pagination offsets into a Zustand or Redux store. That breaks the back button and kills shareable links. The URL is a perfectly fine state container, and the tools for syncing it with React are genuinely good now.

TanStack Router and React Router v7 both give you type-safe access to search params, path params, and hash state. My default now: filter state, sort order, current page—straight into the URL. The component reads the params with a hook, feeds them to a server-state query, and the UI stays in lockstep with the browser’s native navigation. User refreshes the page? They land exactly where they were. No useEffect trying to rehydrate a store from localStorage.

The trade-off is you need a schema for your search params. I use Zod. A small searchParamsSchema that parses and validates the query string means you never deal with NaN page numbers or missing sort keys again. It’s a bit of upfront code, but it wipes out a whole category of bugs that come from manually syncing state between the URL bar and your store.

useReducer for Local Complexity

Not everything needs a library. When a single component or a tightly scoped subtree has tangled state transitions, useReducer is still the cleanest tool. I’m talking multi-step forms, wizards, interactive canvases—places where state updates depend on previous state in non-trivial ways.

The 2026 version: pair useReducer with a typed action union and a pure reducer function exported from a separate file. That reducer gets unit tested without React ever entering the room. The component just dispatches actions and reads the state. I resist the urge to wrap this in a context unless more than two deeply nested children need it. Usually, passing the dispatch function as a prop is plenty.

One trap I keep seeing: people defaulting to Immer inside reducers. Immer is great for deeply nested state, but most UI reducers are flipping a few boolean flags on shallow objects. The proxy overhead is measurable on low-end mobile, especially when the reducer fires on every keystroke in an input. Write the spread syntax yourself for simple cases—it’s three extra characters and zero magic.

Signals Are Here, but Don’t Overdo It

Preact Signals and the newer React bindings have been picking up steam. The pitch is tempting: fine-grained reactivity where only the DOM nodes that depend on a changed value update. In benchmarks, signals-based React components can skip virtual DOM diffing entirely for leaf nodes.

In practice, I only pull in signals for high-frequency updates: real-time dashboards, drawing tools, live text editors. For your average CRUD app, the mental overhead of wrapping values in signal() and remembering to access them with .value isn’t worth it. React’s batching and the React Compiler’s automatic memoization handle most re-render performance problems on their own. I keep signals in the toolbox for the 5% of components that actually need them, not as the default.

The React Compiler Shifts the Math

The React Compiler shipped stable in React 19 and has been refined through 2026. It now automatically wraps components and hooks with the equivalent of React.memo and useMemo where it can prove the optimizations are safe. A lot of the manual memoization we used to scatter everywhere is dead weight.

I’ve deleted thousands of lines of useCallback and React.memo this year. The compiler catches cases I would have missed, and it also catches cases where my manual memoization was actually wrecking referential transparency. The compiler’s lint rules are strict about mutating state and passing unstable references, which pushes you toward cleaner code even before the optimization kicks in.

The practical effect on state management: you can be more aggressive about deriving state inside render functions without wrapping everything in useMemo. A filtered list derived from a parent prop can just be a plain const in the component body. The compiler figures out when to recompute it. This cuts the temptation to push derived state into a store just to get memoization benefits.

Concrete Pattern: Feature Folders with Hard State Boundaries

Here’s a pattern I’ve standardized across all my 2026 projects. Every feature gets a folder. Inside that folder, there’s a state.ts file that exports exactly what the rest of the app is allowed to touch. The structure looks like this:

features/
  dashboard/
    components/
    hooks/
    state.ts
    index.ts
  user-management/
    components/
    hooks/
    state.ts
    index.ts

Each state.ts decides what mechanism to use. For the dashboard, maybe a Zustand store. For user management, custom hooks wrapping TanStack Query. For a settings page, just a plain useReducer. The hard rule: no other feature ever imports from another feature’s internal state file directly. They only import from the public index.ts barrel, which exposes components and a narrow set of composable hooks.

This means you can swap the state mechanism for a feature without touching a single consumer. I migrated a notification feature from a hand-rolled context to Zustand in an afternoon because the boundary was already there. The rest of the app never noticed.

What I Stopped Using

I no longer start new projects with Redux. The boilerplate tax is too high for what it gives you in 2026. RTK Query is solid, but TanStack Query handles non-REST APIs like GraphQL and tRPC with less friction. If you’re deep in a Redux codebase, stay put—but don’t begin a new one there.

I also dropped Recoil. The project is effectively unmaintained, and the atom-family model creates dependency graphs that are a pain to debug visually. Jotai fills a similar niche and has a more active community, but honestly, Zustand covers 90% of the cases where I would have reached for atoms.

Finally, I stopped pulling in external form libraries except for genuinely complex scenarios. React Server Actions plus the native form element and Zod validation cover most form submissions without a single megabyte of Formik or React Hook Form. The browser’s built-in validation and the action prop on forms are good enough now. I default to them and only reach for a library when I need dynamic field arrays or cross-field validation rules that exceed what the platform gives me.

Practical Decision Tree

When I open a ticket that touches state, I run through a quick mental checklist:

• Does this data come from the server? TanStack Query. Done.
• Does this state need to survive a page refresh? URL search params, maybe backed by localStorage through a tiny Zustand middleware.
• Is this state shared across multiple unrelated components? Zustand store, scoped to the feature.
• Is the update logic complex but local to one tree? useReducer with a pure, testable reducer.
• Is this a high-frequency animation or real-time stream? Consider signals, or a ref with direct DOM manipulation.
• Everything else? Plain useState in the nearest common parent.

That checklist covers 98% of the state decisions I make. The leftover 2% are genuinely odd cases that deserve a design doc and a team conversation. If you find yourself reaching for an exotic state solution more often than that, the problem probably isn’t the state—it’s the architecture.

FAQ

Is Redux completely dead in 2026?

Not dead, just no longer the default. Large legacy apps with heavy investment in Redux Toolkit and RTK Query are still well served. For greenfield work, Zustand plus TanStack Query gives you the same power with less code and fewer concepts. Even the Redux team’s own docs now acknowledge this and offer migration guides toward lighter alternatives.

When should I use React Context for state?

Almost never for state that changes often. Context fits static or near-static values: a theme object, a locale string, an authenticated user object that updates once per session. If the value changes more than a few times during a visit, context will trigger pointless re-renders. Grab an external store like Zustand instead, even for tiny bits of global state.

Do I still need to worry about memoization with the React Compiler?

Less, but not zero. The compiler can only optimize what it can statically analyze. If you’re dynamically building objects or functions inside render and passing them to components that aren’t compiled, you still need to pay attention. But most of the useMemo and useCallback calls you wrote in 2023 can safely go. The compiler’s lint plugin will tell you when you’re breaking the rules it depends on.

What about state machines like XState?

State machines shine for workflows with explicit states and transitions: multi-step checkouts, auth flows, media players. For those, XState or a lightweight reducer with a state-transition table works well. For most UI state, though, formally defining every possible transition isn’t worth the ceremony. I use state machines for about one feature per project, not as a blanket pattern.

The state management picture in 2026 is simpler than it’s been in years. We’re finally peeling off the layers of abstraction that piled up during the Redux era. The tools are smaller, the boundaries are sharper, and the compiler shoulders more of the work. The best pattern is the one that fades into the background. That’s what I aim for on every project.