[acemarke]

Hi, I'm a Redux maintainer. I've written extensively about the fact that A) Redux _has_ been overused, B) that many of the complaints were really more about the standard code patterns needed and the "boilerplate" involved, and that C) "modern Redux" with our official Redux Toolkit package and the React-Redux hooks API has solved those "boilerplate" concerns.

Redux is still by far the most widely used state management tool with React apps (my estimates are around 45-50% of React apps use Redux), and we try to give clear guidance in our docs on when it does and doesn't make sense to use Redux.

FWIW, we get highly positive feedback on a daily basis from users who tell us how much they love using Redux Toolkit.

Resources:

- https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet...

- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

- https://blog.isquaredsoftware.com/2021/05/state-of-redux-may...

- https://blog.isquaredsoftware.com/2021/05/learn-modern-redux...

- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

- https://redux.js.org/tutorials/index

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

[pcthrowaway]

Acemarke isn't just "a Redux maintainer", he's incredibly active on Reddit, HN, and Discord, helping people understand Redux better, and also, when it doesn't make sense to use it.

I can't speak to his code contributions, but in terms of documentation, tutorials, and community engagement, most open source projects would be lucky to have similarly prolific contributors.

[acemarke]

Thank you, appreciate it!

FWIW I _have_ written actual code in the libraries too :) I wrote React-Redux v7 by myself, shepherded the design of our hooks API in 7.1, and did all the coding work for v8. Also created Redux Toolkit, added a couple additional APIs, and a bunch of other stuff :)

[trulyme]

Kudos on Redux Toolkit! Anyone who complains about boilerplate with Redux has obviously not tried the Toolkit version. Very impressive.

A bit sad that immer was used (a bit too much magic for my taste), but I can understand the reasoning, and if you just accept it, it's ok.

Thank you and all the other maintainers for your work!!!

[acemarke]

Yeah, concerns about Immer have come up a number of times. The usual concerns people have are:

- Too much "magic" as you said

- Proxy-wrapped data values can be harder to inspect in the browser's debugger

- Seeing "mutating" code may be confusing

I understand those, but from my perspective the benefits of Immer far outweigh any potential negatives.

Ultimately all Immer does is track attempted mutations to nested data, and replay them to create the immutable updates as if you'd done all the nested spread operators yourself. There were dozens of immutable update libs in the ecosystem already (I had listed most of them in my Redux addons catalog), and accidental mutations have always been the number 1 cause of bugs in Redux apps. So, a better way to write immutable updates was clearly valuable.

Immer drastically simplifies all that update logic:

- Removes all the extra object spreads and slices and concats you would have had to write previously, so the code is much shorter and easier to read. It's also more clear what the actual intent of the state update is.

- It also completely eliminates accidental mutations _in_ reducers, and also _out_ of reducers by freezing the state.

So, shorter code, easier to read, and eliminates the #1 cause of Redux bugs.

The tradeoffs are a couple KB of bundle size (which is quickly paid for by having shorter reducers), and needing to understand that Immer is there and doing this "magic" for you.

The one still slightly nagging annoyance is that inspecting Proxy-wrapped data in a debugger is painful, but Immer does supply a `current()` util to extract the plain JS data if you need to, and we document doing that:

https://redux-toolkit.js.org/usage/immer-reducers#debugging-...

So, as with all tools Immer isn't 100% perfect, but it was absolutely the right choice to include it in RTK by default.

[trulyme]

Thank you for the detailed response! My experience seems to be different, as in my opinion immer solves a problem that should not arise in nice code (in most cases) - state should not be that deep anyway. It also takes away a bit of the simplicity of Redux which is its greatest strength, imho.

But as I said, I still highly recommend Redux Toolkit. After dealing with the code using MobX and the complexities brought by its reactions, I would take Redux anytime. Immer is just a small unfortunate detail, but I can live with it.

[theteapot]

> Kudos on Redux Toolkit! Anyone who complains about boilerplate with Redux has obviously not tried the Toolkit version.

You still have to understand Redux's weird boiler plate concepts - actions, action creator functions, reducers, thunks, ... - to understand and use Redux toolkit. Redux is broken from the bottom up.

[trulyme]

They are pretty simple though, and the dev tools are fabulous. I guess we disagree here. :)

Note that I would never (again) use thunk - using such side effects leads to unmaintainable code, at least in my experience.

[tunesmith]

This was exactly my reticence... back when I was learning various approaches and trying to come up with a first-principles derivation of which way to go, I came to the conclusion that I wanted to avoid immer like the plague. So discovering that RTK requires it has made it difficult to consider embracing.

[acemarke]

I'm very curious, what concerns do you have about Immer? fwiw I just wrote a sibling comment that goes into some detail on what problems Immer solves and why we included it in RTK:

https://news.ycombinator.com/item?id=29599980

[trulyme]

Still worth it though, imho - if you have a chance do give it a try. It makes Redux much less verbose and is an ideal abstraction for state management. It never bothered me that much, but forking Redux Toolkit and removing Immer is still an option if you feel strongly about it (should probably be easy).

[codecurve]

That wasn't supposed to read as a criticism of Redux. Redux was just popular enough to be the medium where people discovered that you pay a price for the indirection you need to keep view and state separate.

It won't ever be a one-size-fits-all solution and unfortunately, Redux will have to live with the legacy of plenty of users finding that out the hard way.

That being said, I think Redux Toolkit is a great improvement to the vanilla experience and I'm always impressed by how much I see you out and about on the internet weighing in on these kinds of threads. Inspiring stuff!

[what_is_orcas]

I'll add to that: I love redux and most of the complaints or concerns that I've heard about using redux (from a few teams) have been misunderstandings of how to integrate redux into an existing application or an application design. I think this has mostly come from junior-level folks (independent of title, there are a lot of non-junior devs who can't integrate new patterns into their "senior" level understanding of code, but I digress) and folks who don't work on the front end much (or ever). I was one of those folks until I started a side-project that used redux and I had to implement it in a greenfield project and had the liberty to refactor as I progressed and my mental-model "updated" to integrate the new framework.

[vlunkr]

My complaints with redux were that people couldn't leave it alone. At least in my experience, there was a lot of middleware or libraries built on top of what was a conceptually very simple library.

Using the redux-toolkit and the hooks, with none of the additional junk is a great experience.

[eitland]

Even better is my experience in the project were I work now and were for the first time we are working to remove redux.

I have respect for what acemarke writes above and I think acemarke is right that redux has been overused a whole lot.

[toinbis]

Thanks for great comment! I have one question.

The biggest thing I miss in react ecosystem is decent redux ORM. https://vuex-orm.org is just so great for so many use cases (agree that it might an antipattern in many situations). Is there any chance that https://github.com/redux-orm/redux-orm, which was actually what inspired vuex-orm, would get more love from anyone to become an actively maintained library?

Thanks

[acemarke]

Great question. I actually was one of the earliest users of Redux-ORM, back when I myself was first learning Redux in 2015-16, and I wrote a blog tutorial series in 2017 that showed how to use it.

At the time, the main benefits to using Redux-ORM were easier immutable updates for items in the store, keeping items in a normalized state structure, and managing relationships between items for both lookups and updates.

Since then, Redux-ORM has changed maintainers and had its API tweaked. Meanwhile, we added a `createEntityAdapter` API [0] to RTK, which handles normalization and some CRUD-style updates to the data. Even without those CRUD helpers, you can still do `state.entities[itemId].someValue = 123` thanks to Immer, so immutable updates are taken care of.

At this point, the one remaining thing that Redux-ORM really handles that RTK doesn't is that specifically relational behavior - ie, given a `Post`, look up all its `Comment`s by an array of IDs or something. You can do a decent amount of that with selectors, but yeah, Redux-ORM's API here is nicer.

We haven't tried to provide any of that ourselves because this becomes a much more complicated and app-specific topic. But, I'm always open to suggestions for APIs and use cases. If you have ideas for things that we should consider adding to RTK, please do file an issue so we can discuss details!

[0] https://redux-toolkit.js.org/api/createEntityAdapter

[monocosm]

How did you get to your estimation of 45-50%? That sounds waaaaay too large.

[larsnystrom]

According to npmjs.com react has 13.6M downloads/week and redux has 6.7M. So 45-50% sounds about right.

[sroussey]

Tip: If you want to increase your numbers relative to another package, ship more versions over the same time period.

[ratww]

That figure is "Weekly Downloads", not in total. None of them had updates in less than two months. Also, React has published 10x more versions than Redux. So if anything, Redux might be more popular than GP assumed.

[acemarke]

My estimates are primarily based on NPM download stats for React, Redux, and React-Redux, as well as more anecdotal evidence like "what libs are you using?" polls that I see on Twitter and such.

These are all obviously _very_ imperfect proxies for actual usage stats, but they're all that I see available to work with.

FYI my last attempt to estimate "React state management market share" was in a Reddit thread earlier this year, with download numbers and caveats included:

https://www.reddit.com/r/reactjs/comments/lcgqnd/state_manag...

[robertcorey]

good to see mark fighting the redux fake news in the comments as always.