Stop using Redux (with React) ASAP!!

OK, that is a clickbait headline, but there’s a good reason behind it! I want to draw your attention to an important issue: the pros and cons of using Redux. I will also share some other libraries available for use.

What’s Redux?

Before we dive into why you should stop using Redux, let’s first define what it is. According to Wikipedia, redux is “an open source Js library for data state management”. If you are familiar with web development on React you are probably using Redux. This is due to the fact that from day one, state management on React has been very challenging and there was no global built-in store. To solve this issue developers started using Redux to manage the global state of their applications. There were alternatives to redux like Mobx, which served the same purpose but with a different API.

The global state of the application is the one shared between components and pages. It can be accessed and modified by any component connected to it (named the Connected Component).

What are the pros of using Redux?

· It allows management of the global state.

· Time travel debugging using the Redux devtools

· Able to set up middleware: functions that intercept changes in the state and can alter them.

· Able to do lazy loading.

· The reducer pattern.

Here is a code sample of Redux:

But not everything about Redux is good! Here are some of its shortcomings:

· Single global state. Redux stores all data in a single variable called “store.” This is a problem because on large apps the store will grow, making it difficult to find specific values on it.

· Lazy loading is complicated in Redux. When you lazy load the state, you have to deal with partial states and you must destroy and recreate everything when a new portion is loaded. Did I mention why we need to have the full state loaded in memory?

· Lastly and more importantly, redux is overcomplicated (I should have started there), you might think that this complexity is justified, but is it really justified? What if you can achieve more by doing less, not having to declare reducer, actions, action creator, the mapToProps functions… Not to mention the issue with asynchronous calls: the ones you always have when fetching from the server. You will need a new plugin like Redux-thunk.

Then what can we do? Let’s see some alternatives:

Mobx-react: one of the oldest libraries for state management for React, it uses the observable pattern.

Context API: It is the new built-in global state manager, it was introduced with hooks for functional components. I will show this piece of code and you’ll understand why I don’t like it:

Provides multiple contexts

And here is a code sample for Context API:

Atomic state manager (Jotai/Recoil): they are very similar and both prioritize ease-of-use. The idea behind them is to have the state split into different atoms, with each atom handling a different app domain/context, somewhat like the reducers on Redux. The biggest difference is that the atoms can be imported for any specific component without merging everything in a single-entry point.

Atomic state manager diagram

Advantages:

· Lazy loading is done by default, since there is not a single-entry point. Instead, atoms are imported for the specific component where they will be used.

· No dispatching actions, in fact, the syntax can be almost identical to the useState hook.

· Easy to use, small learning curve.

· Support for overriding the getter and setter of atoms.

· Can use reducers and actions, but they’re optional.

Disadvantages:

· Smaller support community.

· No store access outside components (not a huge disadvantage).

· No middleware and plugins.

Here is a code sample for Jotai:

Atom declaration:

usage in the component:

This is the simplest atom that you can create with Jotai. But keep in mind that the library allows for many features not listed in this article. For more information please refer to the official documentation.

Conclusion

So, as is true with most other articles that use clickbait headlines, the real truth never comes through in a pithy headline. Redux doesn’t have so many problems, and its alternatives are not so perfect. In fact, both of them have their own pros and cons.

I personally value ease-of-use and straightforwardness, and with an atomic state manager, you can easily achieve both.

Redux is overcomplicated but “it is easy once you understand it,” or so says a friend of mine. They are not wrong, but having to write all the boilerplates to start coding to then write more boilerplates to introduce modifications and new functionalities… it makes for a painful and time consuming process (do more by doing less).

So in conclusion, maybe you shouldn’t stop using redux ASAP. You shouldn’t change your state manager on your production web application. Instead, consider using an atomic state manager for your new projects.