Senior front-end interview course · Lesson 04

Choose a store by constraints, not fashion.

Estimated time: about 6 minutes

Libraries are implementation choices. The interview signal is whether you can explain the problem each choice solves and the cost it introduces.

The comparison dimensions

Update model

Actions and reducers, direct store actions, observable mutations, or atom updates?

Subscription model

Whole-context updates, selectors, atoms, or component-local ownership?

Operational needs

Do you need persistence, middleware, devtools, replay, offline support, or cross-tab sync?

Team needs

Will conventions, onboarding, type safety, and predictable review matter more than minimal code?

A useful mental model

OptionStrengthTrade-off
Redux ToolkitExplicit transitions, ecosystem, traceability, team conventionsMore structure and concepts
Zustand-style storeSmall API, direct usage, selective subscriptionsTeam must create its own discipline
Atom-based storeFine-grained composition and derived valuesDependency graph can become difficult to see

Modern Redux note: if choosing Redux today, discuss Redux Toolkit rather than legacy hand-written Redux. See the official Redux guidance.

What not to say

“Redux is always too much.”

“Zustand is always better because it has less boilerplate.”

“Context replaces all state libraries.”

These are slogans, not architecture arguments.

Retrieval challenge

Choose the most defensible answer:

  1. A large organization needs action history, standardized patterns, and many teams contributing.
  2. A small app needs a shared cart and a few UI preferences with minimal ceremony.
  3. A UI has many independent, composable pieces of state and derived relationships.
  1. Redux Toolkit is a strong candidate because traceability and conventions matter.
  2. A lightweight external store or lifted state may be appropriate; avoid selecting a heavy solution by default.
  3. An atom-based model may fit, provided the team can document ownership and dependencies.

Interview-ready answer

“I’d choose based on the state’s complexity and the team’s operational needs. Redux Toolkit is attractive when explicit transitions, traceability, and conventions matter. A lighter store is attractive when the state is shared but the domain is smaller. Atom-based state can work well for fine-grained composition. In every case I’d keep server state in a server-state tool and define ownership boundaries.”

Primary reading

Read Why Redux Toolkit is How To Use Redux Today.

Next lesson: state machines, forms, URL state, persistence, and optimistic updates.