Why I’ve never used Redux. Chapter 1: The reasons

First of All, I hate Redux. And there is a lot of reasons why.

Monolithic

When I was using Vue in my projects, I always hate moving my state to Vuex. You always think too much on whether you need this state to be global or not. Also, making another one store module always sounds as a big task, making your decisions even harder.

You need to create a whole module with its state, mutations, actions, then bind everything to your components… and you also have an awful interaction between modules through namespaces, which also uses string-based API (so say goodbye to TS/Flow support)

Here’s an example from an official Vuex documentation:

This is so bad!

The same with Redux. A bit better, but it still sucks.

And the core problem of both libraries is that your state is global. You don’t have “a lot of tiny local stores” but “one monolith with modules”. And that’s why you often don’t want to put something into it

Most of the time, when you say “I need this state to be global”, it isn’t. Because it’s still local, but you need to use it in a couple of components

Monolithic structure also has another problem. You have to use reselect and other stuff to get your data. Just a couple of questions which noone will answer

1. Why do I need to combine all the states together to then select a small part of it?
2. Why should I keep an eye on state updates, and why my whole app might suddenly re-render when I change the counter?

And you know the answer, why (except React issues)

The answer is — just because. Seriously.

The only OK reason for making your store global is that it’s easier to make SSR support. You can fill the whole state and stringify it in one easy step. But you can do that even with small local stores (will talk about it in my next post)

If I had a couple of small stores, I could use them directly. But with Redux I have to go through the whole state and be sure it’s not being re-rendered by some side-effect

Pseudo-simplicity and different kitchens

Redux also struggles from its “simplicity”.

Nuff said

Because Redux itself doesn’t care on how you’ll use it, there is a lot of libraries to help — redux-thunk, redux-saga, redux-symbiote and even official redux-toolkit. But none of them make it better, none of them solve a ton of boilerplate code and all they do is just the same thing, but a bit different.

I just want to fetch something. WHAT A F***?!

Also, everytime you switch to a new project, you’ll probably see different ways to cook it. Consequently, your codebase has a high chance to become legacy garbage which noone wants to work with.

Creator confirms

And people still use it, continuing to invent new bicycles on top.

Instead of thinking on core concepts and how to make things right, people’re just looking for better oars to paddle easier

Weird API

I always thought that all concepts should be simple-to-use and easy-to-understand. Even if you’re not familiar with programming. We all know about KISS, Occam’s Razor and other beautiful words.

But have you ever thought about how weird is codebase on Redux?

For example, I need to change my counter on button press. So, we have:

• Counter (just a number)
• Button (you know, those things that we click on)
• And action (just make the number bigger)

Without any state managers etc we’d probably make it this way:

Pretty simple and intuitive, right?

Or, using some “abstract” state manager (which I’ll talk in my next post):

A bit different, but still simple and intuitive

What does it look like on Redux:

Alright…

Don’t get me wrong, I totally understand the purpose of reducers. For example, you can make a reducer which change state on different actions etc.

But this whole thing is monstrous. And you can achieve the same flexibility with less verbosity.

And that is only the beginning. Then you make action constants, action creators, nested reducers… Then you install immer, ImmutableJS etc…

And I’m not even talking about asynchronous actions.

Try to explain Redux to anyone who is not familiar with programming. It’s gonna be a tough time

Conclusion

It might look like nagging but that’s how the reality looks like.

I’m really tired to see all those new jobs on React+Redux stack from year to year, just because “everyone knows Redux”.

And I’m also tired to see all these “brand-new state-managers” that have exactly the same core concepts and flaws.

In the next post I’ll talk about solution to all these problems.

Feel free to say what you think in the comments below. And have a good day!