State management: Redux vs Zustand vs Context API

Tick a checkbox and the whole page recomputes. A cart that loses its contents on navigation. A single value duplicated across three components that end up disagreeing with each other. On many applications, these symptoms get blamed on React itself. The real issue is elsewhere: the state was put in the wrong place, with the wrong tool.

Choosing a state manager is not about picking the best tool in the abstract. It is about matching a kind of state to the tool that handles it without needless effort or a performance trap. Most applications get it wrong in one direction or the other: they roll out Redux where three lines would do, or bend the Context API into a global manager until every interaction repaints the entire screen.

Today we settle the choice between the three most common options in the React ecosystem: the Context API, Redux in its modern Redux Toolkit form and Zustand. We start with the only question that matters, dissect the re-render trap that sinks most implementations, then give a method to decide.

Before comparing tools, you have to sort the state. The word covers realities so different that no single tool handles them all well. Three families stand apart.

The costliest confusion is storing server state in a Redux or a Context. You then end up hand-rolling what a data-fetching library already does: caching, request deduplication, revalidation, loading and error handling. For that state, tools like TanStack Query or SWR exist precisely for the job and free the client state manager from data that has no business being there. The rule: a client state manager holds only client state. The rest is server cache.

Since the App Router and React Server Components, part of what used to go through global state no longer needs to exist on the client at all. Data read at server render, a filter carried by the URL, an auth state resolved on the server: each of these lightens the need for client state before you even pick a tool. So the first question stands: does this state really need to live in the browser?

The Context API is often presented as React's native answer to sharing state. That reading is misleading. Context solves one precise problem: getting a value down the component tree without passing it manually from parent to child, what we call prop drilling. It is a distribution mechanism, not a management one. It can neither optimize updates nor subscribe to a slice of the data.

Hence its best-known trap. When a Provider's value changes, every component consuming that Context re-renders, whether or not it uses the part that changed. A Context holding the theme, the user and the cart at once would repaint the cart screen on every theme switch and vice versa. There is no native way to subscribe to user without being notified of changes to cart.

You soften the problem without removing it: split into several independent Contexts so each update only touches its true consumers, memoize the value passed to the Provider with useMemo to avoid creating a new object on every parent render, separate the value that changes often from the one that stays stable. These techniques push the limit back, they do not change the nature of the tool.

Context excels at what it is meant for: a global value that rarely changes and that many components read. Theme, language, authenticated user, a white-label client's branding. For a state that changes several times a second as the user interacts, it becomes a re-render generator. That is where selector-based managers take over.

Redux rests on a strict principle: a single global state, changed only by actions passed to reducers, pure functions that describe how the state transforms. This discipline has a cost in ceremony but offers a rare guarantee: at any moment, you know where every state change came from and why.

Criticized for years for its verbosity, Redux is written today through Redux Toolkit, its official and recommended form. createSlice generates actions and reducers in one block, Immer allows code that looks mutable while staying immutable under the hood and configureStore wires the DevTools and middleware with no manual setup. The Redux Toolkit documentation (opens in a new tab) makes it the default entry point; the hand-written Redux of five-year-old tutorials is no longer the norm.

On performance, useSelector subscribes to a precise slice of the state and only re-renders the component if that slice changes. Redux therefore escapes the Context trap natively. The catch is that a selector returning a new object on every call breaks reference comparison and re-renders anyway. You then derive the data with memoized selectors, via Reselect bundled into the toolkit.

Redux's ceremony pays off under precise conditions: a large application, several developers who need shared conventions, a rich state with cross dependencies, a need for auditing or fine-grained debugging that Redux DevTools deliver with action-by-action time travel, complex asynchronous logic orchestrated by middleware. On a small application, that same ceremony is a cost with nothing in return.

Zustand sits between the two. It offers a global store, like Redux, but with a minimal API surface and no Provider to wire around the application. You declare a store with a hook, put state and update functions in it and every component subscribes to the slice it cares about through a selector.

Here lies its decisive edge over Context: subscription is granular by default. A component reading cart is not re-rendered when theme changes, with no manual splitting or multiple Providers. The store lives outside the React tree, which also allows reads and writes outside components and transient updates that trigger no render at all, useful for high-frequency state like a cursor position.

The approach is detailed in the Zustand documentation (opens in a new tab). It is often the balance point for a mid-sized interactive application: more structured than a stack of Contexts, far lighter than Redux and without the first one's re-render trap. The downside of that flexibility: fewer imposed conventions, so a team discipline you have to hold yourself to keep the store from becoming a catch-all.

The real divider between these tools comes down to one mechanism: how a component decides to re-render when the state changes. It is what separates an interface that stays smooth from one that stutters as soon as it grows.

With Context, there is no decision: React re-renders every consumer the moment the Provider's value changes, full stop. The component has no way to say it only cares about one field. On a value that changes often, the number of useless re-renders grows with the number of consumers.

With Redux and Zustand, the component supplies a selector, a function that extracts the slice of state it cares about. The library compares the selector's result between two updates and only re-renders if it changed. Reading state.cart.count stays painless when state.theme flips. That level of subscription, absent from Context, is what keeps performance in check as the state grows.

The selector has its own pitfall: comparison is by reference. A selector returning a new array or object on every call, such as items.filter(...) or { a, b }, always fails the comparison and re-renders on every update. The fix is well known: return primitive values when you can, or memoize the derivation. This re-render cost is the state-side counterpart of the render pipeline dissected in optimizing render performance (opens in a new tab).

These questions are not mutually exclusive: one application often combines useState for local, TanStack Query for the server and a single global store for the real shared client state. The trap is not picking the wrong single tool, it is trying to run everything through one.

A state manager puts each piece of data where it makes sense, only re-renders what must be re-rendered and asks for no more code than the problem requires. The Redux versus Zustand versus Context debates miss the point: these tools don't all answer the same question and the best choice depends on the kind of state, the size of the project and the team.

Concretely, well-managed state means interactions that respond instantly, an interface that stays smooth as it grows more complex and code still readable six months later. It is less visible than a successful animation but it is what decides whether that animation runs at 60 frames per second or stutters on the first click.