Redux versus Zustand state management

WHAT THIS TESTS Your ability to reason about state management tradeoffs instead of defaulting to the library you know. It checks whether you understand the cost of boilerplate, the role of context providers, and how subscription models affect re-renders.

A GOOD ANSWER COVERS Redux centralizes state in a single store mutated only through dispatched actions and pure reducers, with immutable updates and a Provider component wrapping the tree so connected components subscribe. Redux Toolkit reduces boilerplate but the action-reducer-selector triad remains. Zustand is provider-less: create() returns a hook you import anywhere, state lives in a closure, and you mutate via set. Components subscribe by passing a selector, re-rendering only when that slice changes, which gives fine-grained performance without connect or useSelector ceremony. Redux offers richer time-travel debugging and a large ecosystem; Zustand wins on minimal API surface and speed of iteration.

COMMON WRONG ANSWERS Saying Zustand has no middleware or devtools, claiming Redux cannot do selective subscriptions, or insisting one scales better universally. Confusing provider-less with global mutable singletons that break testing is another error.

LIKELY FOLLOW-UPS How does Zustand avoid the Provider yet still work in React Native? When would Redux Toolkit be the safer choice for a large team? How do both handle persistence?

ONE CONCRETE EXAMPLE A counter in Redux needs an action type, a reducer case, a dispatch call, and a useSelector read. In Zustand, const useStore = create(set => ({ count: 0, inc: () => set(s => ({ count: s.count + 1 })) })) is the entire store, and a component calls const count = useStore(s => s.count) directly, with no wrapping Provider anywhere in the tree.