Can React Hooks fully replace Redux for state management? Why or why not?
Often yes, but not always. For most apps: useState + Context + React Query covers 90% of what people used Redux for (server state goes to React Query, local to useState, cross-tree config to Context). What Redux still offers: time-travel devtools, middleware ecosystem (logger, sagas, listeners), strict action-based mutation pattern useful for large teams. For complex client domains with many cross-feature interactions, RTK still earns its place.
What hooks + ecosystem cover
The Redux use cases that hooks + standard tools handle well:
| Need | Tool |
|---|---|
| Component-local state | useState / useReducer |
| Cross-tree config (theme, auth) | Context |
| Server state (cache + revalidate + mutate) | React Query / SWR / RTK Query |
| Form state | React Hook Form + Zod |
| Cross-tree app state (cart, editor) | Zustand or Jotai |
| URL state | Router |
For small-to-medium apps that historically used Redux for everything, this stack covers it with less boilerplate.
What Redux still offers
Time-travel devtools
Redux DevTools lets you scrub through every action and inspect state at each step. Invaluable for debugging complex flows. Zustand has a devtools middleware too, but Redux's is richer.
Middleware ecosystem
redux-thunk(now baked into RTK).redux-sagafor complex async orchestration.redux-observablefor Rx fans.- Logger middleware.
- Persist middleware.
For apps with intricate async choreography (real-time multiplayer, payment flows with rollback), this ecosystem is hard to beat.
Strict action-based mutation
Every state change is a typed action. Easier to audit, log, replay. For 20-engineer apps with strict review processes, this discipline matters.
RTK's createSlice + RTK Query
RTK collapsed Redux's boilerplate. RTK Query is a credible React-Query competitor with the same store. Hard to dismiss.
Big domain models
Editors, design tools, multiplayer apps — state shape is genuinely complex with many interactions. Redux's normalized + action-driven pattern fits.
Where hooks alone struggle
- Coordinating many cross-feature interactions without a central store → ad hoc.
- Cross-component side effects that need to react to actions → easier with middleware.
- Audit trail of every state change → harder without action discipline.
- Time-travel debugging → not available.
When hooks-only is the right answer
- App shape is request → display → mutate, mostly server state.
- Teams want minimal ceremony.
- Server state is the dominant kind of state.
- No need for time-travel / middleware orchestration.
When Redux earns its place
- Complex client-side state (editor doc, multiplayer, design tools).
- Large team needing audit / convention.
- Need middleware ecosystem for async orchestration.
- Cross-feature interactions are central to the product.
What I'd choose today
| App | Choice |
|---|---|
| CRUD dashboard | React Query + useState + Context |
| E-commerce | React Query + Zustand for cart |
| Editor / design tool | RTK or Zustand (with deliberate slice structure) |
| Multiplayer realtime | RTK with middleware OR custom store + WebSocket |
| 50-engineer enterprise app | RTK with slice ownership |
Interview framing
"For most apps today, yes — useState for local, Context for cross-tree config, React Query for server state, Zustand for cross-tree app state. That covers what people historically reached for Redux for. What Redux still offers: time-travel devtools, middleware ecosystem (sagas, logger, listeners), and a strict action-based discipline that helps large teams audit changes. So for complex client-side domains (editors, design tools, multiplayer) or 20+ engineer codebases with strict review processes, RTK still earns its place. The single most important shift is moving server state OUT of any client store and into React Query — that's where 80% of Redux's old job goes."
Follow-up questions
- •What's the case for RTK Query over React Query?
- •When have you migrated from Redux?
- •What does a saga do that React Query can't?
Common mistakes
- •Picking Redux by default.
- •Putting server state in any client store.
- •Confusing 'Redux is dead' with 'never use Redux.'
Performance considerations
- •Selector subscriptions are key in either tool. Avoid full-store consumers.
Edge cases
- •Multiplayer state with optimistic + reconcile.
- •Cross-feature side effects via middleware.
- •Persisting only a portion of the store.
Real-world examples
- •Trello (legacy Redux), Linear (custom store), Excalidraw (Zustand), enterprise apps still using RTK.