Why Redux Is More Relevant Than Ever Today
By: Jason Lee Hodges
Tags: JavaScript, React, Programming, Technology, Redux

Why Redux Is More Relevant Than Ever Today

Photo by Hadija Saidi on Unsplash

Over the last year or so I have encountered several opinions suggesting that the React ecosystem is recommending the deprecation of Redux in their projects in favor of moving towards “modern React” using the Context API. A few episodes on React Podcast have alluded as such (with such notions as “have you migrated your Redux over to Context yet?”) and there have been multiple articles published that exemplify this viewpoint. I’ve heard from bootcamp graduates whose instructors have rushed through the Redux content of their curriculum because it was “too complicated” and “people don’t use it anymore anyway.” Additionally, I’ve heard this sentiment spread to a brand new self-taught developer as he was starting on a new project at our company:

“I thought people were kinda moving away from Redux in favor of Context…“ — Anonymous self-taught developer

I myself even suggested that perhaps Thunks, a tool for making asynchronous action calls, were obsolete — which I no longer think thanks to Redux Toolkit and some inconveniences that I have since experienced when using only custom hooks in projects. Honestly, I think we all kind of just got excited about new React features and thought “This is the future!” They are cool, and they empower a lot of useful things. But getting rid of Redux is not one of them.

Perhaps the sentiment has arisen from a handful of controversial headlines without a lot of really in-depth analysis, but Redux is not dead. In fact, I think it is more relevant than ever. Of course, I don’t mean to come off officiously on the subject. It might not work for every project. In fact, Dan Abramov, the creator of Redux, has suggested that perhaps you don’t need Redux in your project in an article back in 2016. But for my organization, I have found several reasons why we will continue to use Redux for the foreseeable future. Hopefully new react developers will consider these as well instead of simply going along with the recent sentiment surrounding the Context API.

The nature of my work allows me to build a lot of greenfield applications with varying levels of complexity. This gives me a perhaps somewhat unique perspective on what is useful and what is not. I took the opportunity at a time when I had a lot of new projects hit my queue all at once to test varying implementations of state management to help determine for my organization where we were over-investing our time and what was truly useful for catching bugs and building reliably architected solutions. Those variations included building apps with:

Only useState hooks (trying to architect in such a way to avoid as much prop-drilling as possible).

hooks (trying to architect in such a way to avoid as much prop-drilling as possible). A completely vanilla implementation of Redux.

Only the Context API.

An implementation of Redux Toolkit.

What I found was that, even in my applications that were supposed to be small, scope creep and edge cases inevitably arose that ultimately made them larger and more complex. One of the main benefits that have been argued for the Context API is that it is simpler and makes more sense with smaller applications. But after this experience, I would argue that there is no such thing as the mythical “small app.”

Additionally, developers on my team who picked up Context for the first time started running into bugs related to implementing it with mutable variables. Refactoring their code to make it safely immutable led to basically re-implementing the Redux API (via reducers functions), but without the benefit of the awesome Redux Dev Tools. Seriously, the Redux Dev Tools are so good, I never need to use a breakpoint or a console.log when I’m debugging. The ability to retrace each action that has been dispatched, manually dispatch new actions in a live app, trace exactly where the action was dispatched from in your code, and see the full state and the state diff for each dispatch are not worth giving up for the “simplicity” of the Context API.

On the point of simplicity — the main reason the Context API is said to be more simple than Redux is due to the reduction of boilerplate code. However, a safely implemented Context application does not have that much less boilerplate than Redux. And these days, Redux Toolkit has significantly cut down on the boilerplate. Redux Toolkit is a big differentiator in this debate. I probably stumbled upon it later in the game than I should have, but its relative simplicity over a vanilla implementation of Redux basically shuts down the Context API argument completely.

TL;DR

There is no such thing as a “small app,” which is where the Context API is meant to shine. Redux Dev Tools are not worth giving up for a marginal reduction in boilerplate code. Redux Toolkit reduces the complexity of a Redux implementation to be comparable with Context API complexity.

Conclusion

Redux, in my opinion, is not only not dead — it is more relevant than ever. With the addition of Redux Toolkit, the state management capabilities surrounding Redux have gotten better than ever. New features introduced in Redux Toolkit, like RTK Query, seem pretty killer (I haven’t tried it yet, but I really want to). The folks contributing to Redux Toolkit have done such a good job that my organization will be paying close attention to that library for the foreseeable future as we see them as thought leaders in the industry.