Article summary
One question comes up at the beginning of every greenfield React project I work on: how do we manage global state? We always debate the merit of using Redux versus rolling our own global state management solution using React context and hooks. We’ve ended up choosing Redux for each project, and here’s why.
(This post specifically compares Redux with custom state management via React context. You should also check out other state management solutions like Recoil, MobX, and Apollo.)
Community Support
The main reason I still use Redux is its wide adoption by the React community. Redux has been around for about five years, so there are plenty of resources to help guide our implementation decisions. And the official Redux website has plenty of information to help you get started or maintain a project that uses Redux.
Extensions
Plenty of libraries have been made to extend Redux since it’s so widely adopted. Why roll my own asynchronous action solution when I can use thunks or sagas? Why implement a way to undo actions when I can use redux-undo or undox? So many problems have already been solved by the Redux community.
Redux Devtools could be used as an argument itself when deciding between Redux and a custom solution. It’s a boon to reducer development to see the order in which actions have been dispatched and the diff of state between each action. At the time of writing this, I was unable to find a widely adopted debugging tool that is comparable for useReducer.
Reinventing the Redux Wheel
At the end of the day, a custom state management solution would end up looking very similar to Redux, so why wouldn’t I use Redux?
All that being said, Redux is not the answer all of the time. Every software problem is different. Some projects won’t need global state management. Others will work fine without all of the extras that Redux provides. At the end of the day, you should make your decision based on the problem at hand.