Why You Should Use Redux in 2024

All right. Good morning. My name is Mark Erickson, and today I'm very excited to talk about why you should use Redux today.

A couple of quick things about myself. I am a senior front-end engineer at Replay where we're building a time-travelling debugger for JavaScript applications. If you haven't seen it, please check it out. It will save you so much time investigating issues and trying to fix your flaky tests. Come by and ask me about it later. Very happy to show it off. I am an answerer of questions. I will answer questions pretty much anywhere there is a text box on the internet. I collect any kind of link that looks even remotely useful. I write extremely long blog posts, and I'm a Redux maintainer. I've done most of our documentation, and I created Redux Toolkit, but most people know me as that guy with the Simpsons avatar. It's become a trademark.

Why are we even having this talk anyway? Well, historically, the Redux team has not actually spent really any time at all trying to encourage people to use Redux. In fact, if anything, we've actually spent most of our time telling people you shouldn't actually use Redux in this situation, and part of that is because Redux has been used in a lot of places it really shouldn't have been. So our goal as maintainers is not like we're trying to win market share. We just want Redux to be a very good tool so that if you choose to use it, it works well for you. But we still see a lot of questions about when does it make sense to use Redux?

How many of you have ever used Redux in any form at all? Okay. Basically the entire room. Cool. How many of you have ever used the modern Redux toolkit package? Okay. Somewhat fewer hands. That's concerning. And just out of curiosity, how many people here have never used Redux? Okay, like, ten people. All right.

So what am I trying to do today? I am a big believer in understanding the history of tools, why were they created, and what problems were they trying to solve. So we're going to take a quick look at the history of Redux and the circumstances surrounding its creation. We're going to talk about how the ecosystem has evolved over time. We'll talk a bit about some of the trade-offs of using Redux. And I'm going to give some positive reasons why it's worth considering using Redux today. Now we've got a limited time, the clock is already ticking. I'm not going to try to compare Redux versus other libraries. I'm not even going to talk about, like, how awesome Redux toolkit is. I've done talks like that before. You can look them up on your own time.

A quick history of Redux. React came out publicly in 2013. And a year later, Facebook announced this concept called the Flux Architecture. And the issue was that they were having trouble keeping state in sync across different parts of their application. Most famously, the notifications button was showing, like, different values than the rest of the UI. And they were having trouble being able to understand how data got updated. So they came up with a pattern called the Flux Architecture, which used words like stores and dispatchers and action objects. And these might sound familiar. And that's because Redux actually got all these terms from Flux initially. It's, like, the reason they're named actions and not events is because Flux used that name first and we just kept the name from Flux. Now Facebook did not release a full library for Flux. Just a couple utilities.

Just a couple utilities. And so the React community began pumping out dozens of different Flux-inspired libraries, each with mostly joke names based on Back to the Future. I refer to this period as the Flux Wars.

In February 2015, Dan Abramov put up a blog post called The Case for Flux, where he talked about the benefits of using this pattern in React applications. Being able to cache data, separating updates from what happened, and having a single source of truth were some of the benefits mentioned. In mid-2015, he put up another post called the Evolution of Flux Frameworks and began working on Redux.

Redux was designed originally as just another Flux library. It was intended to make it easy to maintain code that updates state and provide a clear history of dispatched actions. Functional programming principles were incorporated to make the code more testable. The API design was intentionally organized by type of data, such as users, posts, and comments. Redux was announced at React Europe in mid-2015 and Redux 1.0 was published a month later.

And it should be easy to extend the library to build in more functionality. Now a couple of years later, I wrote a pair of blog posts that I titled The Tao of Redux. And I was trying to expand on this and further explain what were the goals of Redux. And so I listed a few things. Redux was designed originally as just another Flux library. It wasn't even meant to be a full-blown thing. It's just an example. But the big goal is making sure that it's easy to maintain code that updates state. As part of that, the history of dispatched actions should have meaning. You should be able to see the user did this, the user did that, and read through the history. It is intended to have some functional programming principles. It should lead you to write more code that's testable. But the data flow and the update logic should be very explicit. I also talked a little bit about the API design. We intentionally designed it so that the reducer logic would be organised by your type of data, the users, the posts, the comments. The actual Redux APIs should be pretty minimal, but the library itself should be very extensible. So these were the goals behind Redux's creation.

So in mid 2015, Dan and Andrew began collaborating on Redux. Dan announced it at React Europe, and a month later, Redux 1.0 was published. It was a two-month development cycle. Redux immediately became popular, and, within a year, it had killed off all the other Flux libraries, and the community began to assume that if you're using React, you have to use Redux. Note that the React team didn't say this, and the Redux team did not say this. This was like a community thing.

So the Redux libraries continued to evolve. We put out a React Redux version 5 in 2016, which improved performance, version 6 at the end of 2018, which used modern context inside, but at the same time, the React ecosystem was changing as well because hooks came out in March 2019, and everybody was demanding that we put hooks in React Redux and every other library at the time. We redid the internals of React Redux to use hooks inside of Connect shortly after that, and then we published our own hooks API with use selector and dispatch in June of 2019. At the same time, there were a lot of complaints about how to use Redux. I've gotten sick of hearing the word boilerplate over time. We created Redux Toolkit to make it easier for people to use Redux. We shipped Redux Toolkit 1.0 in October of 19, and a year later, I rewrote our tutorials to teach Redux Toolkit as the default.

In 2021, we shipped the RTK query data fetching library, very similar and inspired by React query and SWR and Apollo. A year after that, I marked the original create store method as deprecated. It still works fine. I didn't break anything. But I wanted to encourage people and let a lot of people know that RTK exists. Finally, last year, I spent the entire year battling with publishing tools and packages and ESM and common.js and finally shipped RTK 2.0 and major versions of all of our other libraries to have better packaging and better common.js compatibility as well as dropping things like IE11 support. You can see that Redux itself has evolved quite a bit over time.

If we go back and think about why did people even choose Redux to begin with, I can think of a few different reasons. One is that the original legacy React context API was actually very broken. You could pass values down through the tree, but you couldn't update those values consistently, so a lot of people turned to other libraries to avoid that. Redux was the best Flux library implementation at the time, at a time when the React community was agreeing that Flux is the way to manage state in React applications.

You could hot reload components at the time, but the way it worked was limited, and reloading a component would actually throw away all the component state, and so in order to keep state around as you were doing development, people would often use Redux just to keep the state in memory. And then of course, there were thought leaders. Again, not the React team, not the Redux team, but senior engineers, Twitter people, whatever, who were insisting that, well, of course, you should be using Redux. There were also some good architectural reasons. React is designed with functional programming principles in mind, and so is Redux. React, a state, is limited to the shape of your component tree. State goes down as props to children, and so sometimes different parts of the component tree need to access the same data, and so having an external state management library can make that easier. And finally, there are architectural benefits to moving state out of the UI layer, keeping the UI relatively simple, and just saying, here's a thing that happened, let the updates happen over here.

Finally, predictability and observability. Redux gives you a very consistent data flow pattern. You click on the UI, handler runs, dispatch in action, reducer updates, selectors read data, components re-render. It's a bit of work, but it's a very consistent flow the whole time. Redux reducers and selectors are pure functions. They're just values in, arguments out, which makes them very easy to test, and, of course, the Redux dev tools make it easier to see what happened in the application.

So which of these reasons still actually matter today? Well, okay, fine, most of those historical reasons are pretty much dead at this point. We've got modern context. Most people don't even remember that flux was a thing. Fast refresh works great. And trust me, the thought leaders on Twitter are not insisting you should use Redux today. But the concepts of architecture and predictability and observability are still very relevant as we build apps.

So how has the React ecosystem changed? Back in 2015, the problem space was really a discussion about client-side state management and also the concept of side effects. And at the time, side effects included data fetching implicitly, but the ecosystem has evolved. Probably around 2017, 2018, the discussion began to shift from client-side state management and side effects to caching state from the server, which is the same thing but with different terms and a different mindset. And so we began to see purpose-built tools like Apollo and React Query that were designed for solving that particular use case. And well, okay, yes, early Redux was kind of hard to use and people put it everywhere, a lot of places they shouldn't have, and so people, like any tool, it went through an adoption curve. Ooh, here's the hot new thing that will solve all of our problems. Wait, we've actually just found a bunch of new problems with the hot new thing. And so people began to figure out that there were actually issues with it. And on top of that, newer developers began to be told you have to use this thing called Redux, but they never used any earlier libraries and they didn't know the pain points that Redux was designed to solve. When Dan was writing the original Redux docs, he said, I have to figure out how to explain flux to backbone developers. That's not a problem we have today at all. We've also seen a big shift from single-page applications to server-side rendering, multi-page applications. There's less need for strictly client-side state. We have a lot of tools for fetching data on the server and we have purpose-built data-fetching libraries. There's also a lot of other solutions for passing data through the component tree. Modern React context works very well. There's many other state management libraries like Joty and Zeustend and signals and everything else. So there's a lot of other options for the kinds of things people might have used Redux for back in the day.

But on the other hand, Redux has changed as well. We've gone from the original Redux library, which basically had nothing built in and you had to write all the code yourself, to Redux Toolkit, which provides APIs for basically all the common things you do with Redux. Creating a store, writing reducers, fetching data. We've basically solved the boilerplate problem and we have a bunch of built-in features to prevent common mistakes, like accidental mutations. We've got the RTK query library for data fetching. We teach this as the default way to fetch data with Redux today. You don't have to write thunks and reducers and sagas and all this other code just to fetch some data from the server. You say here's an endpoint, here's the URL. You get a hook that you just call on your component and it does all that work for you.

We've shifted away from the original React Redux Connect API to hooks. Today React wants you to use function components and hooks. We're going along with that. Hooks are easier to use than the Connect API. It works better with TypeScript. It's a much simpler usage pattern. React Redux has a lot less boilerplate today. Early Redux had no real opinions. We said here's a half dozen different ways to do things. You figure out which one you want to do. That meant that different early Redux codebases had a lot of different structure. Today we have the style guide with a set of opinionated patterns on this is the right way to use Redux. We teach those patterns with our tutorials and with using Redux Toolkit. And we teach a testing approach that says use your UI through React testing library and MSW and test your Redux code that way. Everything has tradeoffs. As a senior developer, this is my favorite word of all time, tradeoffs. There are good points and bad points with every tool. Nothing is perfect.

As Dan Abramov said early on, Redux is designed to answer the question, where did a piece of state come from and why did it change? It's not designed to be the single fastest way to run the app. It's not going to be the single shortest way to write the code, but it does make things very predictable. So what are some of the tradeoffs of Redux? With Flux, you have this indirection.

You dispatch an action instead of saying state value equals 1, 2, 3. This means there's a little more code, you have to go back and forth between the UI component and the reducer. This can be a good thing. It means your UI is simpler. It means you can look in one place for the reducer logic. This is easier to scale as the application grows, but it does mean that you have to understand that some things happen here and some things happen over there.

Similarly, a single store is great for having one place to look for the data. You know where the reducer logic is, you can see it in the dev tools, you can have additional logic based on the actions that are dispatched. This can definitely be abused. The concept of a single source of truth probably got overemphasized in some ways. Let's put literally everything, every single value including is the drop down open in Redux? That was a little too far, trust me. Also, Redux forum, Eric Rasmussen, I love you, but that was not a great idea. But similarly, the idea of state updates with reducers and slices. This means that more of the code in your application is pure and predictable, but it also means that you have to write these immutable updates, and sometimes the logic doesn't always divide cleanly. And finally, managing state as plain JS objects and values. This means that you can easily serialize the data, you can persist it, it can be displayed in the dev tools. Sometimes it means that, well, I really wish I could put a date into my Redux store or use a set or something, and you're really not supposed to do that.

Okay, so the title of the talk is why you should use Redux today. I lied. In a lot of ways, I'm too reasonable to actually do the full sales pitch. We just talked about trade-offs. It is kind of hard to say you should unambiguously use Redux when I just listed all these things that aren't perfect about it. And honestly, there's a lot of other great tools in the ecosystem. So ultimately my goal here is not to tell you you literally should or ought or must use Redux, but rather to say that Redux is still a very valid choice today for a lot of the reasons we've talked about. So let's finish with a quick look at the positive things about Redux that make it still worth considering today. It does provide a very consistent architectural pattern. Separating your state from the UI does have a lot of benefits as you build real world applications. The data flow is predictable. You know where to look for the actual state update code. It does give you a better view of what's happening in the application.

You can see the semantic history of the actions. The Redux dev tools are incredibly powerful. It is very widely used. I hate to use this as an argument. It's just like, well, it's the most popular library. Everyone's using it. You should still use it. But it is a valid point. You saw, basically everyone in this room has used Redux. People understand it. It's well documented. This is a valid reason to choose a tool.

It's stable. You understand what it's there. It currently has slightly better update performance than React context. The upcoming React compiler will help with context performance. There's a discussion of a context selector feature. At the moment, fewer components will re-render if you're using Redux than if you're using React context. Redux toolkit exists. We've solved most of the problems that people run into when they're using Redux today. That includes the RTK query data fetching layer which makes it simple and straightforward to say here's the end points, give me a hook, fetch the data.

Finally, it works great with TypeScript. We put a lot of effort into making sure that our types handle all the inference so you just say here's the type of my state, here's the type of my action, and it works. And even though we assume that most people are using Redux with React, it still works without React in many other situations as well. These are not necessarily the most persuasive arguments in the world. I could make good arguments for using ZooStandard, Joe Tye, or other tools. But these are valid reasons to consider using Redux today and examples of why it is still the most widely used client-side state management library for React.

That's all I've got, and I'm well past time, so thank you very much. Thank you. Thank you.

Thank you. Somebody asked, actually I like this one, can Redux be completely replaced, completely with like standard ease reducing context, and should you? That is about the one millionth time I've seen that question. And I will actually slightly shortcut it by saying I've seen that question so many times that a couple of years ago, I wrote a blog post entitled Why React Context is Not a State Management Tool and Why it Does Not Replace Redux. Now, the slightly longer version of that is that yes, useReducer plus useContext look very similar to Redux, and they do have some similar usage patterns. There are significant differences. Redux keeps the state outside of the React component tree, and as I just mentioned, there are currently rendering differences in how many components will re-render when you put a new value in context versus having a new value in the Redux store. So if you haven't seen that blog post, please check it out. If you search for Redux versus context differences, it should be up there, blog.isquaredsoftware.com. I wrote like 6,000 words about it. It's probably easier if you read that blog post. That's very in-depth.

Yeah, brilliant. Okay, so what are your go-to rules to decide whether something should end up in a centralized store or not? The biggest one is about how many components in the application are probably going to need access to the state. How long does the state need to live, like will the state need to live longer than some of the components in the tree? How often does it get updated? Will I have benefits of seeing the actions being dispatched to understand what the user did? Will it really be helpful to see the state in the Redux dev tools? There's no single hard and fast rule. Like I said, you can literally put the is the dropdown open state in Redux. That's probably not great because it really most likely only one component cares and it probably doesn't need to stick around very long. You mentioned the predictability of it throughout and that does seem like that's the useful part of the whole thing, but also living outside of the context of the component itself.

So yeah, awesome. This one's shot up the charts. Would you recommend Redux at all when using server-side rendering? Ask again? Would you recommend Redux when using server-side rendering at all? I'm not sure. So this is one of those cases where it's certainly technically possible to do it. I don't know if I specifically recommend it, per se. So we definitely have examples. Redux has been used in some server-side data fetching cases from the beginning in the same way that you could even use React's render to string early on. You'd use the same basic pattern. You would create a Redux store, per each individual request, don't share it across requests. That's bad. Dispatch, I think, to do some data fetching, wait for it to complete. At that point the UI has finished rendering and then you might pass the serialized data back to the UI to hydrate the store on the client side. So it's absolutely a thing you can do.

We've got some examples of it. Should you do it? That's more up to you and your application. Are you using Redux at all? Do you have SSR needs? Nice.

Moving to micro frontends. In a micro frontend setup using module federation, how heavy is it to dynamically inject reducers of the micro apps into the shared global store? Okay. So one of the potential advantages of Redux, and this is an example of moving state out of the component tree, is that it is entirely possible to pass the same Redux store instance to every separate React tree in different parts of an application. And they'll all see the same state. We did add an API in Redux Toolkit 2.0 that is designed to help with dynamically injecting reducers into the store. It's an API called combine slices, and it actually makes it easier to inject reducers than some of the older handwritten patterns as well. Nice. Thank you.

With form state, url state, and asynchronous data fetching as their own state, what's actually left for Redux to manage? This is an excellent question. This goes back to my point. Like, yes, you could put literally anything in Redux, and unfortunately, people have at different times. But if we, like, especially with server state, if you choose to use a tool like React Query to manage your fetching and caching server state, all that's left is a smaller piece of client state at that point, and you probably don't need to use Redux for a relatively smaller piece of client state. Now, you could use Redux for all that, RTK Query for the data fetching, plus some additional slices for everything on the client, but there are tools that are specialized for each piece. So, again, this is why I can't in good consciousness stay here and say, like, you must use Redux, because there are different tools that are good for the same kinds of things. So Redux provides RTK Query for the data fetching. It provides create slice for client side state. If you choose to use Redux, it will work well, but if you've chosen to use something like React Query or whatever, then you've cut out maybe some of the reasons why you might have chosen Redux in the past. I like it. Nothing in technology is ever, you 100% must use this, right? I guess we're at React Summit, but then the opening speech was about solid. It depends is always the answer, right?

What is a good example of when you should not use Redux? Form state is a good one. Like I said earlier, the Redux community tried to put Redux everywhere early on, and that included the Redux form library, and in retrospect, dispatching actions on every keystroke was not a great idea. For forms today, we would say just use local components state or even, like, uncontrolled components, React forms, something like that. Because you're editing the form, and then dispatching action at the end with the update saying now it's done, now the rest of the application can use it. Go do what you want with it. Nice.

Go do what you want with it. Nice. Don't use it for forms. For updating form state. Yeah. All right.

Is RTK query always the way to go, or are there cases where using just plain fetch is better? So, RTK, well, that's a slightly false question. RTK query, on the one hand, it's a general-purpose async state manager. TK Dodo, the author of React query has written some posts saying it's not a data fetching library, it's an async state manager, because it's just here's a promise, track the status, cache the result. RTK query is the same thing. We default to having a fetch wrapper as the default way to use it, but you can use it for any promise async function at all. We certainly teach RTK query as the default way to do any data fetching in a Redux application. It's a tool, it has its limits, and there are probably some edge cases where you might need to write some thunks or some other logic instead.

That actually brings on to a further question down, which actually sort of gets outside of that data fetching, I guess, and asking, like, would Redux be good in back-end for like Web sockets and gaming at all? So that goes to what I was saying earlier. Redux itself, the core is entirely UI agnostic. We've always assumed, like, 90% of our users will use it with React, but you can use Redux anywhere that JavaScript will run, with or without any UI. And so, yeah, I've seen people use it, like, in Discord bots to keep track of status. Yeah, and Web sockets doesn't make a difference or you write your own... It's logic, you dispatch actions, it runs. Nice.

Redux Saga lets me abort fetching, is that possible in RTK query? Let's see, what? Redux Saga lets me abort fetching, is that possible? Not exactly. So this has actually come up pretty frequently in the RTK query related issues and feature requests. Our stance so far has been that there isn't enough reason to abort a data fetch because the result will get cached and even if a component no longer says it needs that data right now, you might come back and need it later, it's just another cache entry, and if no component needs it, it'll get garbage collected later. We have had enough requests for aborting, like, literally aborting a fetch request that it's something we might look at adding in a future version. Awesome, that's good to hear. And if you want that, I guess send in a request as well? There's no more issues, no more issues. Just a thumbs up on an existing one? Yes, please. No more new issues on that, cool. Oh, this is interesting.

Oh, this is interesting. Is there a plan to have Redux packages on JSR? Not specifically. For those who don't have context, JSR is a new JavaScript package registry, kind of a competitor to NPM created by the Dino folks. I can try it. Honestly it's not anything I've put any time or thought into, like if someone wants to submit a PR and help me do that, that'd be cool. I haven't put anything up to JSR yet either, but as far as I've looked in the docs, it doesn't seem too hard. Also I spent my entire last year fighting with our packaging and I'd really rather not go back to that any time soon. A little PTSD on the package management. I wrote a 7,000 word blog post on all the problems I'd run into trying to get ESM to work properly. I think I read that one, yes. Terrific stuff. Yeah, I guess JSR is supposed to be easier than that. I hope so. Yeah. Hopefully it wouldn't be that much easier. It can't get worse.

All right, I think that's... Probably about out of time. Yeah, right. On the horror of package management, we'll finish there. Thank you so much, Mark. Please give another round of applause to Mark.