DEV Community

Is Redux Dead?

OpenReplay Tech Blog on February 10, 2021

by Kristofer Selbekk React revolutionized front end development as most people knew it when it was first released. This new approach to writing c...

Read full post

Mark Erikson • Feb 10 '21

Nitpick: one 's' in my last name, not two :)

FWIW, I've written multiple posts on this topic that cover various aspects, from "context vs Redux" to "when does it make sense to use Redux?":

I also recently put together a rough estimate of React state management library "market share". Summary:

Redux: 45-50%
Apollo: 15%
XState: 8%
MobX: 7%
Redux Toolkit: 4.5% (overlaps with Redux)
React Query and SWR: 2.5% each

Finally, I strongly recommend reading through the newly rewritten official tutorials in the Redux docs, which have been specifically designed to teach you how Redux works and show our recommended practices:

"Redux Essentials" tutorial: teaches "how to use Redux, the right way", by building a real-world app using Redux Toolkit
"Redux Fundamentals" tutorial: teaches "how Redux works, from the bottom up", by showing how to write Redux code by hand and why standard usage patterns exist, and how Redux Toolkit simplifies those patterns

The older patterns shown in almost all other tutorials on the internet are still valid, but not how we recommend writing Redux code today.

It's also worth reading through the Redux "Style Guide" docs page, which explains our recommended patterns and best practices. Following those will result in better and more maintainable Redux apps.

selbekk • Feb 10 '21

Sorry about your name Mark!

As I mention in the article - Redux today is a much better experience than ir was only a few years ago 😊 you’ve done a great job maintaining a very important peoject that’s important for hundreds of thousands of projects across the globe.

That being said, and as I state in the article, Redux is used in many situations where it’s not needed - at least not anymore.

GaneshMani • Feb 11 '21

Big fan of your work Mark. I've been following you and your work for quite some time. I recently wrote an article on the Redux toolkit with a use-case. cloudnweb.dev/2021/02/modern-react...

shadowtime2000 • Feb 11 '21

Not every day you have to correct a typo of your own name in a tech article.

Mark Erikson • Feb 11 '21

hah, usually it's someone trying to put a 'c' in there :) Lots of "Erickson"s in the world, not nearly as many "Erikson"s :)

Eric Haynes • Feb 16 '21

I've met very few "Erik"s and NEVER an "Erick", and yet people try to spell my first name that way all the time. ;)

OpenReplay Tech Blog • Feb 10 '21

Editor's Note: The name's been fixed, sorry about that.

John Kazer • Feb 13 '21

Hmmmm xstate at 8%, what do you consider it's role to be and should it be used more?

Mark Erikson • Feb 13 '21

I haven't used it myself, so I can only offer a sort of generic suggestion based on seeing it described.

XState is primarily about "state machines" - having a known set of values for a given set of data, and transitioning between those in predefined possible ways based on events that occur in the system. So, it's the combination of "if in state X, and event Y comes in, transition to state Z".

It's very likely that more apps should be using something like XState for logic that is sort of an ad-hoc or implicit state machine.

As David Khourshid has pointed out numerous times, Redux reducers can be used to write state machines, but most commonly aren't, because the focus is more on the actions / event types rather than "if we're in state X, only handle these cases".

John Kazer • Feb 14 '21

I really like XState, but I don't have much experience of building large apps so don't know practically if it scales in a usable way. My main problem is the state of mind transition from thinking about actions to thinking about states - they aren't quite the same thing. But if you make the switch life somehow seems better!

Eric Haynes • Feb 17 '21

It's essentially just splitting the thought process down the middle. Our user story might say, "when I click the X button, then the dialog closes". Thus, we start thinking about the implementation in those terms as well. But instead, break it up into:
"when I click the X button, it sets the opened state to false", then without any care for how the state got there, "when state.opened is true, display the dialog".
Once you not only make that transition, but start to do it reflexively, it'll really have you reevaluating how you think about software in general. ALL software is really just a state machine.
A database is a "store", with memoizing SELECTors (pun intended), and INSERT is just an action with type: 'table_name/insert', payload: values.
REST APIs have essentially the same CRUD operations as databases.

At its core, React is just an abstraction around the subscriber model that notifies your components when a value changes. Other subscriber models include Promises, AWS lambda functions, and file watchers. ;-)

Arthur Zhuk • Feb 15 '21

Don't use Redux in 2021. Check out React's Context API and react-query.

Khorne07 • Feb 10 '21

Great post. I love to use redux, in most cases is very helpful having your aplicacion state isolated from your components. Is true that needs more boilerplate but it worth it. I have faced issues when I need to mutate a state variable too often, and Redux was my day savior in the end. Also Redux dev tools are amazing to keep trace of your state and debug so I'll keep using Redux over Context API.

selbekk • Feb 10 '21

Thanks!

Those are fair points - and if the tradeoff is worth it to you, then Redux is a great choice for your projects. My argument is that many people have seen it as the default choice for any app - no matter what requirements your app might have. It shouldn’t be.

Oxford Harrison • Feb 10 '21

This "default choice" problem has actually eaten far too deep than we are taking about it. It's the reason why devs reach for a framework even for as little as a "coming soon" page in the first place. And this poor thinking just makes it look like frameworks are a thing for the less informed.

It's also funny how we only ADMIT the downsides of something after seeing something else. I remember talking every now and then about state management complexity without anyone admitting it. Hopefully soon, we can begin to question the entire idea of much of the frameworks themselves and admit the overkill.

I find it the most-worthwhile thing to push for native platform implementation of the same paradigms on which UI frameworks are based: modularity, reusability, and reactivity. I can as well expect most devs to only later admit to the current state of complexity when browsers finally ship with proposals like OOHTML - .github.com/webqit/oohtml.

Lesley van der Pol • Feb 11 '21

I actually still love Redux and despite it being big I haven't found a "big" reason to just go reach out for something different. While we do use React context we ran into some massive performance issues on a context provider that became big and was serving too many different form-related components. We managed to solve around 80% of the re-rendering that was happening within this just form simply by moving the context to Redux and creating a somewhat ConnectedForm, and making good use of reselect.

Eric Haynes • Feb 16 '21 • Edited

Your examples of context contain a problem which inflates the relative performance benefit of Redux. With Redux, the higher order component flavor has a mapStateToProps function which extracted the props you were interested in and returned an object of props.

const mapStateToProps = (state) => ({
  foo: getFoo(state),
  bar: getBar(state),
});

An important feature of Redux was that this object was shallowly compared to the object returned the last time it ran. If the contents of the resulting object were the same, it didn't rerender your connected component. pseudocode:

if (last.foo !== current.foo || last.bar !== current.bar) {
  rerender(<Component {...current} />)
}

(The modern API use the useSelector hook, but it has similar optimizations, just on a per-value basis)

Now let's compare that to the Context example above.

<LocaleContext.Provider value={{ locale, setLocale }}

When it renders, it passes the object supplied to value down to any consumers later in the tree. It also has an optimization so that, if the value of value is the same, it doesn't trigger the consumers to rerender.

BUT, there is a problem. The value of a Provider doesn't have to be an object; it can be a string, null, 42, whatever. Thus, it only compares the top level value, not its contents. Every time the Provider rerenders, it creates a NEW object (albeit with the same contents), so every time all of its consumers rerender. In effect (also pseudocode):

// always true!
if (last !== current) {
  consumers.forEach((consumer) => consumer.triggerRerender())
}

The solution: ALWAYS use useMemo when passing an object as the value of a Provider. You might often hear not to overuse useMemo. It's often a premature optimization, and since it carries some overhead, it can potentially DEGRADE performance rather than enhancing it. But your custom Provider has no idea what's being rendered below it, and due to Murphy's law, we must always assume that the biggest React tree the world has ever seen has a consumer of your context at the top of it (and with something like locale, it probably IS at the top of your App!). So the provider becomes:

const LocaleProvider = (props) => {
  const [locale, setLocale] = React.useState("en-US");
  const value = React.useMemo(() => ({
    locale,
    setLocale,
  }), [locale])

  return <LocaleContext.Provider value={value} {...props} />;
};

John Merchant • Feb 16 '21

In most cases I'd normally be using Redux, I find React's useReducer in combination with the Context API can solve the problem already. The only downside is you lose the handy DevTools integrations with frameworks such as Redux, MobX, Overmind.

Imad • Feb 15 '21 • Edited

I am now using mobx on production level react native app. I am using the opinionated version, mobx-state-tree, the feeling is quite similar to redux but with much less code, not touch the full mobx yet, and the fear of adding too many codes when you want to create a new store on redux is gone.

I decide to pick this after found out that Infinite Red team choose this as their primary for their RN-boilerplate, Ignite, arguably the best boilerplate for RN. Now I am not sure if I will use Redux again in the future.

John Peters • Feb 10 '21 • Edited

For me, Redux and Flux were always anti-patterns. They were one of the reasons I stayed away from React. Glad to see Hooks instead.

Arthur Zhuk • Feb 27 '21

What do you mean it doesn't support arrays? Are you following the patterns stated in the docs? It doesn't do normalization as most users don't actually need a normalized cache. It works with gql: react-query.tanstack.com/examples/....

Arthur Zhuk • Feb 24 '21

I haven't used Redux Toolkit actually and can't speak on it. I've used vanilla Redux, thunks, redux loop, and MST.

It could just be the aspect of novelty that's attractive about using new state mgmt patterns but something about using just React state, Context, and a lib like RQ instantly feels good.

Arthur Zhuk • Feb 23 '21 • Edited

Yes and I've built a large React app with mostly react-query and a little bit of Context. It's a much more pleasant DX than using Redux. I've used Redux for multiple similar-sized projects. It's awful in comparison to my personal experience. People will have their own experience with state management solutions of course.

Steve Huckle • Feb 14 '21 • Edited

Honestly? I've been using Redux for years and more often than not just drop it into my apps today without giving it too much thought. However, whether I should, or not, is another matter entirely! This fantastic article has given me plenty to consider!

Itamar Yatom • Feb 13 '21 • Edited

Nice article. Overmind seems cool, first time I heard of it.
I think you should put more emphasis on "Redux toolkit", since it is very powerful and has a different development experience than vanilla Redux

James Mikrut • Feb 11 '21 • Edited

When we built Payload CMS, we did include Redux at the beginning but ended up entirely removing it as Hooks and Context matured. Payload's admin panel has a ton of different global states going on but we have a well-designed solution that's completely devoid of Redux. I don't think that I'll ever use it again personally. Nothing wrong with it, just ... properly designed context works by itself for me.

Jonathan Schneider • Feb 11 '21 • Edited

Most state like the content of input fields or whether a modal is open, is only interesting to the component that contains them!

I wonder why modals should be a good example for that, being kind of "global" in their very nature. Just imagine having two components with custom pop-overs, contained in a third component. If you only want to allow one pop-over to be open at any time, your third component would need to include handler-logic, although it's a separate concern.

I agree that the developer experience for state management could be better though, and hooks really help in that direction, independent of the library.

Laughing Kookaburra • Feb 27 '21

After I read this post, I was sad because I already converted a certain part of my app to use RTK. Then I went and read about the React Context and was relieved. Hence this reply.
React docs cautions using Context API in large-scale devs focused on components. React doc says it can become complicated and component reusability will be affected. For small apps not focusing too much on component-based development Context API may be ok. I believe React is all about building components.

With regards to RTK, the examples out there doing a good job might need a bit of decluttering. In fact, RTK is pretty simple just use it and it will work. To be honest, I am just about to enter Async, Thunks Saga, my opinion might change when I enter there then I might change my reply

Francisco M. Delgado • Feb 10 '21

What's crazy is that Redux used context before React used context lol

Eric Haynes • Feb 16 '21

React always had context. The Context API we're familiar with today replaced a previous implementation that was rather quirky, and had some fundamental bugs. Originally, Redux was implemented on top of that, but now it uses the new Context API.

reactjs.org/docs/context.html#lega...

Arthur Zhuk • Feb 23 '21

Redux was a good solution 5-6 years ago. These days there are better solutions that have less physical and mental overhead to accomplish the same thing.