When Redux Is Right
Redux shines in applications with genuinely complex shared state — state that multiple unrelated components need to read and write, state that needs to be debugged through time with the Redux DevTools, state that has to survive across routes. For that use case, Redux Toolkit has made it nearly painless.
The projects where it served me best were enterprise dashboards where fifteen different components needed to respond to the same WebSocket events, and the predictability of a single store was invaluable for both development and debugging.
The Three Signs It's Time to Move On
Sign one: you're writing boilerplate for state that only one component uses. If a piece of state only matters to one component and its direct children, useState is the right tool. Putting it in Redux is cargo cult architecture. Sign two: every new feature starts with 'add it to the store' regardless of whether sharing is needed.
Sign three — the one that finally convinced me — is when junior developers on the team are afraid to touch state. When the data flow is so opaque that people prefer to duplicate state rather than trace through the selectors to find what they need, the architecture has stopped serving the team.
Key takeaways
- Co-locate state as close to where it's used as possible — only lift to Redux when two genuinely unrelated component trees need the same mutable state
- Redux DevTools time-travel is genuinely invaluable for complex state bugs — don't give that up until you have a replacement debugging strategy
- The team's ability to reason about state matters more than architectural purity — if developers are scared to touch the store, something has gone wrong
Conclusion
The question isn't whether Redux is good or bad. The question is whether it still fits the shape of your application. Revisit that fit every six months. Sometimes the answer changes.
Enjoyed this article?
Vivek Kumar Singh
Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan
