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.