State management is a classification problem.
Estimated time: about 6 minutes
The strongest interview answer is rarely “I prefer Redux.” It is: “I identify who owns the state, how long it lives, and where the source of truth is. Then I choose the smallest mechanism that fits.”
The decision lens
Who needs it?
One component, a subtree, many components, the URL, or the server?
How long?
One render, a screen, a session, a refresh, or across devices?
How can it change?
Simple assignments, coordinated actions, async sync, or strict workflows?
The option map
Local UI state — useState
Modal visibility, input text, selected tab. Start here when one component owns the state.
Shared state — lifting and props
Move state to the closest common owner when nearby components coordinate.
Complex transitions — useReducer
Use a reducer when related event handlers form a small domain model.
Cross-cutting values — Context
Context transports theme, locale, or auth. It is not automatically a complete state-management solution.
Server state — TanStack Query or RTK Query
API data is remote, asynchronous, cacheable, and potentially stale. Use a server-state tool for caching, invalidation, retries, and synchronization.
Client stores — Redux Toolkit, Zustand, atoms
Use an external store when broad client coordination justifies it. Choose based on structure, subscriptions, persistence, debugging, and team conventions.
URL state — search parameters
Filters, pagination, and selected views belong in the URL when they should survive refresh or be shareable.
Workflow state — state machines
Use explicit states and transitions when booleans can create impossible combinations.
Interview-ready answer
“I don’t choose one state library for everything. Local UI state stays local. Nearby shared state is lifted or reduced. Context handles cross-cutting dependencies. API data belongs in a server-state cache because freshness and invalidation matter. For broad client state I’d consider Redux Toolkit, Zustand, or an atom-based store based on the team’s needs. For workflows with strict legal transitions, I’d model a state machine.”
Retrieval practice
Classify these before revealing the suggestions:
- A dropdown’s open/closed state
- A product filter that should be shareable by URL
- The current user returned by
/me - A checkout flow with payment retry and cancellation
- A cart used by the header, product page, and checkout
- A derived total price
- Local UI state:
useState. - URL state: search parameters.
- Server state: TanStack Query or RTK Query.
- Workflow state: reducer or state machine.
- Shared client state: lift it if practical, otherwise a client store.
- Derived data: calculate it; do not store a duplicate.
Primary reading
Read React’s Managing State chapter, especially “Choosing the State Structure,” “Sharing State,” and “Scaling Up with Reducer and Context.”
Ask follow-up questions whenever anything feels fuzzy. The next lesson covers redundant state, server versus client state, and Context/global-store performance traps.