Why Do You Need To Rethink About Using Redux

This blog discusses the downsides of using Redux for state management in React-based projects and provides reasons to reconsider its usage. I point out the complexity of writing DRY and SOLID Redux code and the lack of opinionation in Redux, leading to various implementation approaches and potential difficulties in understanding code. Maintaining Redux-based applications can be challenging, requiring excessive code for small changes. Additionally, the blog highlights the heavy reliance on multiple dependencies when using Redux, which might not be necessary in every project.

If you have worked on some react-based projects, you know that most people are using redux for handling server state management or even UI and form state management. This is so common that using it is like a decisive convention and developers don't consider alternative solutions.

Although I like redux personally and the things that it offers, you can see how I like to use it in the how to write redux clean code blog, but in most of the projects, using redux is just like a Seppuku but without honor!

1. Redux downsides

IMO, choosing redux for handling server state management should be done obsessively for the below reasons.

1.1. Complexity

Writing DRY, SOLID redux code is god's work, most of the approaches you take, may have problems in their implementation and that's because redux code is complex and it doesn't worth its difficulty unless it's necessary.

1.2. Unopinionated

As it is mentioned in the redux official documentation:

The Redux core library is deliberately unopinionated. It lets you decide how you want to handle anything, including store setup, what your state contains, and how you want to build your reducers.

This is a good thing sometimes because it gives you flexibility but that's not the point here. The point here is because of that, there are so many ways to set up redux implementation, so whenever you work on a project, there is a strong chance you won't be able to understand what is going on in the code for a while. Add different middlewares like redux saga, redux thunk, redux observable, or ... as multipliers to these problems. Of course, there are some packages to fix this issue like redux toolkit but not everyone uses it.

1.3 Hard to maintain

If you use redux to develop your application, even small changes in functionality require you to write excessive amounts of code. You either ought to do it or violate the principles of clean coding (if there is anything left).

1.4 Too many dependencies

For a simple next.js application you will need all of these packages: redux, react-redux, redux-saga or any other middleware to handle side effects, redux-devtools-extension for debugging and probably next-redux-wrapper for next.js applications. It's just an overkill.

1.5 Better alternatives

As state management tools have evolved, now there are so many new approaches to consider that any of them are good for each use case. I will talk about them in the Alternatives part below.

2. When to use redux

If you're not sure, let's take a look at the redux official documentation itself:

Redux is most useful in cases when:

• You have large amounts of application state that are needed in many places in the app

• The app state is updated frequently

• The logic to update that state may be complex

• The app has a medium or large-sized codebase, and might be worked on by many people

• You need to see how that state is being updated over time

• Are so many of your states needed in more than one place in your app?
• Does these states change frequently?
• Is updating logic that complex?

If your answer to all of those questions is yes, you can use redux freely, consider reading how to write redux clean code to know how, but otherwise, I can't see a reason why.

3. alternatives

There are some alternatives to redux. any of them have their downsides and benefits that we will discuss but you can read more about them in their documentation.

3.1 Context API

You probably already know about Context API, on first glance it looks like a great first-party way to handle server state management, but it is not. It wasn't meant to be like that but with a combination to react hooks, we can use it as a global state managing tool. The biggest reason it shouldn't be your first option is that it doesn't use smart memoization, even a small change in a part of its state will trigger a rerender for all the subscriptions which causes the entire descendant component tree to rerender unless you memoize those components yourself.

This issue is fixed in redux when we use useSelector to subscribe to a certain slice of a state. but it's still an ongoing process for react. Until react releases useSelectedContext hook, we can use use-context-selector library to subscribe to a certain slice of context. and prevent unnecessary re-renders and performance leaks.

You can use Context API for handling UI state and server states that don't change frequently but I think it's better to consider other alternatives and leave context for UI states only.

3.2 Jotai, Valtio

Both of them are great alternatives for handling UI state if you have a nice learning appetite.

3.3 SWR | React query

SWR and react query are new ways to handle state management and other interesting pieces of stuff. I think both of them are great alternatives and endgames. There is a table from react-query documentation that will help you to choose one over the other.

I've used both of them and SWR more. Here in the 5th section, I've described the way I like to implement custom hooks with useSWR.

Conclusion

After using alternatives you will see how much time you have saved for yourself and how many refactors are not needed anymore.