Lesson 26 of 30

State Management Libraries

Q: Which state management approach would you use for a new app — Context, Redux, Zustand, or an atomic library — and why?

A strong answer covers: Each answers 'how is shared state updated/read' differently: Redux (structured, action-based), Zustand (minimal ceremony), atomic libraries (narrow per-atom subscriptions), Context (built-in, coarse re-render granularity); The recurring differentiator is subscription granularity — how much re-renders when one piece of state changes; Client-state tools aren't a substitute for server-state tools (React Query/SWR) — pick the right category of tool for the job.

Redux, Zustand, Jotai, and Context all answer 'how does shared state get updated and read across an app' — but they disagree sharply on ceremony, granularity, and how they interact with re-renders.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A component subscribes to one small piece of frequently-changing shared state via plain React Context. What performance problem is it likely to hit that an atomic library (like Jotai) would avoid?

Every Context consumer re-renders on any value change, not just the piece it actually reads — atomic libraries subscribe more narrowlyContext can only hold one piece of state total, unlike atomic librariesContext requires a network round-trip on every read, unlike atomic libraries

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on State Management Libraries

What interviewers actually ask about this, and what a strong answer has to cover.

Which state management approach would you use for a new app — Context, Redux, Zustand, or an atomic library — and why?

A strong answer covers

Each answers 'how is shared state updated/read' differently: Redux (structured, action-based), Zustand (minimal ceremony), atomic libraries (narrow per-atom subscriptions), Context (built-in, coarse re-render granularity)
The recurring differentiator is subscription granularity — how much re-renders when one piece of state changes
Client-state tools aren't a substitute for server-state tools (React Query/SWR) — pick the right category of tool for the job

Likely follow-ups

Why does Context become a performance problem specifically for frequently-changing state?
What's the actual tradeoff Redux's extra structure buys you, versus Zustand's minimal approach?
How would you decide whether an app even needs a dedicated state management library at all?

Practice these with the AI interviewer →

The plain-language idea

Once state needs to be shared across many components that aren't close together in the tree, useState plus prop-drilling gets unwieldy. The libraries in this space all solve that, with real, different tradeoffs:

Redux — one global store, updated only through dispatched actions handled by pure reducers (the MV-architecture lesson's unidirectional flow, formalized). Maximum structure and traceability; real boilerplate cost, though modern Redux Toolkit cuts a lot of it.
Zustand — a small store created with a plain function, read via a hook, updated by calling functions directly — no actions, no reducers, no providers wrapping your app. Much less ceremony, less built-in structure.
Jotai / Recoil — atomic state: many small, independent pieces of state (atoms) instead of one big store, so a component subscribing to one atom only re-renders when that atom changes, not on any unrelated state change.
React Context — built into React itself, but (from the Context lesson) re-renders every consumer on any value change — genuinely fine for rarely-changing, low-frequency values (theme, current user), a real performance problem for frequently-changing state.

State libraries: skipping the layers that don't careStep 1 of 3

Prop drilling: passing 'theme' through 5 layers of components that don't use it, just to reach the one that does.

What people usually miss

Watch out

This is exactly the server-state-vs-client-state lesson's distinction, applied to picking a tool. None of Redux/Zustand/Jotai are built to handle caching, staleness, or request deduplication well — that's what React Query/SWR are for. Mixing "client state" tools and "server state" tools for their respective jobs, rather than forcing one to do both, is the modern default.
More structure isn't free, and less structure isn't automatically better — Redux's ceremony buys traceability at scale (every state change has a name, in one place); Zustand's simplicity can turn into scattered, hard-to-trace mutations in a large enough app if no conventions are enforced.
"We need Redux" is often reached for by habit, not by an actual measured need. Many apps' genuinely shared state is small enough that Context (for rarely-changing values) plus local useState/useReducer covers it completely, with real ceremony saved.

Why this matters in interviews

"Which state management library would you use for this app, and why?" is a real, common systems-design question — a strong answer connects the choice to actual re-render/subscription granularity and to the client-state-vs-server-state distinction, not to which library is currently trendiest.