Why You Should Use Redux in 2024

Spanish audio is available in the player settings
Rate this content
Bookmark

I've always avoided trying to do sales pitches for Redux, and tbh most of my time has been spent telling people when they _shouldn't_ use Redux :) But I still see lots of folks asking "_when_ should I use Redux?", and "how does Redux compare to $OTHER_TOOL?". So, I figure it's worth actually doing a talk where I cover the actual benefits and reasons to consider using Redux today.

This talk has been presented at React Summit 2024, check out the latest edition of this React Conference.

FAQ

Redux has evolved from being a minimal library requiring a lot of boilerplate code to Redux Toolkit, which simplifies common tasks like creating stores and reducers, and includes features like RTK Query for data fetching. Modern React features like hooks have also been integrated into Redux.

While useReducer and useContext can mimic some Redux patterns, they differ in that Redux keeps state outside the React component tree, leading to fewer re-renders and better performance in some scenarios. Redux also offers powerful developer tools not available with useReducer and useContext.

Redux Toolkit is an official, opinionated, batteries-included toolset for efficient Redux development. It simplifies the process of setting up a Redux store, writing reducers, and includes RTK Query for data fetching, effectively solving many common issues and reducing boilerplate code.

Yes, Redux is still relevant for modern React applications. Although there are many state management tools available, Redux provides a consistent and predictable pattern for managing state, especially in larger applications where state needs to be shared across many components.

Yes, Redux can be used with server-side rendering (SSR). You can create a Redux store for each request, dispatch actions to fetch data, and then pass the serialized state to the client for hydration. However, whether to use Redux for SSR depends on the specific needs of your application.

The benefits of using Redux today include a consistent architectural pattern, predictable data flow, powerful developer tools like Redux DevTools, wide usage and community support, better update performance compared to React context, and strong TypeScript support.

Redux is best suited for managing state that is needed by multiple components, state that needs to persist beyond the lifecycle of a single component, and state where it is beneficial to have a clear history of actions and updates. It is less suitable for managing local component state or form state.

Redux was created to manage client-side state in React applications, providing a predictable state update pattern and solving issues related to keeping state in sync across different parts of an application, as initially addressed by the Flux architecture.

Mark Erickson is a senior front-end engineer at Replay, a maintainer of Redux, and the creator of Redux Toolkit. He is known for his extensive documentation work and his Simpsons avatar.

Some trade-offs of using Redux include the added complexity of dispatching actions and writing reducers, the need to manage immutable updates, and potential overuse of a single store for all application state. However, it provides a predictable state management pattern and powerful developer tools.

Mark Erikson
Mark Erikson
33 min
14 Jun, 2024

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Mark Erickson explains the history, creation, evolution, and benefits of Redux. Redux was designed to make state updates and action history maintenance easy, incorporating functional programming principles. Redux Toolkit was created to simplify Redux usage. Redux is still a valid choice for its consistent pattern and separation of state from UI. The decision to use Redux depends on the specific use case and the need for centralized state management.

1. Introduction to Redux

Short description:

Mark Erickson explains why you should use Redux today. He discusses his role as a senior front-end engineer at Replay, his involvement in Redux maintenance and documentation, and the creation of Redux Toolkit. The talk aims to address the historical context of Redux and its appropriate use.

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?

2. The History and Purpose of Redux

Short description:

The speaker discusses the audience's familiarity with Redux and the Redux toolkit. They express their intention to explore the history, evolution, trade-offs, and positive reasons for using Redux. The speaker briefly mentions not comparing Redux to other libraries or discussing the Redux toolkit. They then provide a quick history of Redux, starting with the release of React in 2013 and the subsequent introduction of the Flux Architecture by Facebook to address state synchronization issues.

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.

QnA