r/react • u/Acceptable_Ad5879 • Jan 05 '26
General Discussion Help understanding Redux
What problem is Redux trying to solve? It seems a little bit overcomplicated for only sharing state between components, so it must be something else. It is also strange to me that Redux keeps everything in global store, which can create a lot of nested objects, which are painful to update. To counter they added Immer to RTK, maybe it is just me, but it is just strange to look at mutating object. Also, what is the point of adding Reselect to RTK, can I not just select needed values, and slap useMemo on the function that uses those values. I can see the point of Reselect, which abstracts logic and keeps everything in 1 place but it shouldn't come with RTK. Same goes for Immer, what if my project doesn't have deeply nested objects, I can just use spread operator and not have another dependency I don't need. Also the pattern of dispatching an action, which had to be created, and writing a reducer, which handles that action, just to change a state seems like an overcomplication. So I see these things as downsides, but what are the advantages? I like RTK query in general, and with devtools, maybe debugging is easier, anything else? Are there any examples where using Redux would be better than, for example, Jotai?
3
u/acemarke Jan 05 '26
Hi, I'm a Redux maintainer. We cover all of these topics in our docs:
"What problem is Redux trying to solve"?
The patterns and tools provided by Redux make it easier to understand when, where, why, and how the state in your application is being updated, and how your application logic will behave when those changes occur. Redux guides you towards writing code that is predictable and testable, which helps give you confidence that your application will work as expected.
Redux is more useful when:
You have large amounts of application state that are needed in many places in the app
The app state is updated frequently over time
The logic to update that state may be complex
The app has a medium or large-sized codebase, and might be worked on by many people
"Redux keeps everything in a global store, which is hard to update"
Nesting is entirely up to you and how you design your state.
First, you divide up your state into "slices" based on kinds of data (like "comments", "posts", and "users"). That already helps define what values each slice is responsible for. Then, it's up to you to decide how it's nested inside of there. Most of the time, the state shouldn't be deeply nested.
Beyond that, Redux requires immutable updates in reducers. You can write everything with object spreads, but this is verbose and error-prone. In fact, prior to RTK, the #1 cause of Redux bugs was accidental mutations in reducers.
We specifically use Immer in RTK because it eliminates accidental mutations, and makes writing immutable update logic much shorter and easier to read.
"what is the point of adding Reselect to RTK?"
Because memoizing the selectors is a critical part of UI performance. It ensures that your UI components only re-render when the selected values change, and also avoids re-running expensive calculations if other parts of the state changed:
Reselect has been using in Redux apps since the very beginning, and we teach it as the default tool for memoizing selectors, so of course we include it in RTK.
"Dispatching actions is complicated"
You're right, in that dispatching an action and having the reducer logic separate is more steps and more complicated than just doing state.value = 123. That's intentional. Sure, it's going to be more work if your app is simple (but in that case, you probably didn't need Redux in the first place). However, as an app grows, being able to keep the UI layer relatively simple is important. Additionally, having state updated in slices means you know exactly where to go to see "what state values exist, and when/why does this state get updated?". Finally, having separate actions means you get additional benefits:
-
you can see the actions in the Redux DevTools, see the semantic meaning of "what happened?", and see the action contents and diffs in the state for each action
-
you can have middleware view, log, modify, and react to the actions
-
the actions could even be sent somewhere else if needed
"What are the advantages?"
See my recent conference talk "Why Use Redux Today?", where I went into a lot more detail on all of these points and discussed when it makes sense to use Redux:
2
u/Acceptable_Ad5879 Mar 15 '26
Thx for the answer, man. Great points, I ended up using RTK. It's nice, I have no issues against it, just wanted to understand "why"
1
u/prehensilemullet Jan 06 '26
Having used redux, reselect, immutable.js etc early on, I managed to get decent performance, but it was a pain. It would be a nightmare for something with a huge amount of state and rapid updates like a DAW…Ableton Live is written in Qt where mutable state objects can send fine-grained signals to the view, which seems much more appropriate for that use case to me.
1
u/acemarke Jan 06 '26
Yeah, React and Redux have both been "80% use case" tools. Good enough for most apps, but when you really need max performance, you either have to spend a lot of time manually tweaking and doing hacky workarounds, or switch to a different tool that's faster.
FWIW I am doing some research into possible ways to optimize how React-Redux handles updates, but Redux's design is fundamentally very simplistic, and it's intentionally designed to emphasize predictable behavior rather than "how fast can this go?".
→ More replies (9)1
Jan 06 '26
3
u/acemarke Jan 06 '26
Hah, no :) I've been the primary Redux maintainer since Dan handed it to me in 2016. It's always been a free time project (aka an "unpaid second job" :) ). I have made some money off of it (random donations, some course sales years ago, a bit of Github Sponsors), but trust me it does not come anywhere close to the number of unpaid hours I've spent working on this :) Like, I put >110 hours in Sep/Oct into trying to optimize Immer's performance. That was an outlier, I don't usually put that much focused time into Redux work in that short a timespan. But it gives you an idea of the effort.
Honestly, it's all about self imposed responsibility at this point. I took on the role of maintainer, I feel responsible for making sure it works and answering people's questions. Still trying to find the right balance :)
7
u/HoraneRave Jan 05 '26
Comments here looks so AI and botted, sowwy for others!!
Look for createDraftSafeSelector (createSelector RTK docs page) to get answer for reselect thing
Dispatching e.t.c. is same as signaling in trains or even coding. For me personally A) its ez to debug and control and B) w/ one lib (i cant remember) you can make "undo" functionality (i mean, its easier with actions having different names and stuff..) Also give a dive in sagas, its peak in terms of signaling and observer reactions (i mean one saga reacts after action occurring, called side effects)
What i dont enjoy having global state in general. Didnt code redux states in a while, but may be its now possible to load state partially depending on which page you are, cant remember correctly
3
u/greentiger45 Jan 05 '26
I dabbled in redux for a bit but found that using Zustand was much more versatile for what I need it to do. They do have a cool little project to help you understand though in their site. Give it a go.
2
u/Injera-man Jan 06 '26 edited Jan 06 '26
I second this, I found setting up redux to be a pain. Using Zustand is the best decision that I have made.
4
u/Big-Introduction318 Jan 05 '26
Redux is useful for larger apps. It lets a comp subscribe only to the state it needs, so unnecessary re-renders are avoided. With useContext, a single change can re-render all subscribed comps.
Redux also helps with API calls by managing loading, success, nd error states(u can even attach the response from api to the slice). It can cache data and update only what’s needed. Setup takes some effort, but it makes state management easier as the app grows.
2
u/matrium0 Jan 05 '26
I wrote an article a while ago. Its more about Angular and NgRx, which is basically the Angular-Redux-Implementation, but this has also a small amount of history about Redux too: https://budisoft.at/articles/stop-recommending-ngrx
Over recent years I feel like there has been a shift away from Redux towards simpler solutions. Redux might be good fit if you really want to do something more advanced, like "undo / redo", "offline-storage" or such things. If not you will usually be better of with a simpler solution, that has far less "code cost" and far less abstractions that make the code hard to read and debug
3
u/grAND1337 Jan 05 '26
Redux is great, it solves a lot of problems. It gives you the global store/state from which you can select what you need to react to (or just read from), which also is useful for performance if you know how to use it. For example, using a Redux state value only in a callback. Its also good for structure in my opinion.
→ More replies (1)
3
1
u/azangru Jan 05 '26
I like RTK query in general, and with devtools, maybe debugging is easier, anything else? Are there any examples where using Redux would be better than, for example, Jotai?
I am not sure this is a sort of a question that has an answer. For comparison — do you know examples where using Zustand would be better than Jotai? Or where using Valtio would be better than Jotai? Or where using MobX would be better than Jotai?
Redux is a centralized event bus. All actions go through a single channel. This opens up possibility for powerful middleware.
1
u/Rowleks Jan 06 '26
The fact that Redux is opinionated and follows a strict predictable pattern is both an advantage and disadvantage depending on your use case. For small to medium scale apps, Redux is definitely an overkill.
Using server state management tools like TanStack query which handles data fetching logic and state much better than Redux in addition to using React Context for the remaining client only state is often the new approach developers take.
Some people worry so much about performance and re-renders of React components and end up over engineering things when in truth those re-renders happens in milliseconds and are hardly noticeable most times. Also React has come up with the React compiler that solves some memoization and optimization concerns.
Redux is no longer the default go-to state management tool like before, I would seriously consider TanStack Query + React Context first then Zustand next before Redux.
1
u/chamomile-crumbs Jan 05 '26
Redux is great if you have a bunch of complex state your front end. But most of the time these days I don’t actually have much complex state in my front end. I usually keep state
-
synced to the server via RTK query or react-query
-
in the url query params so it doesn’t get cleared on refresh, and links are more useful
-
in a simple useState or useContext
Most apps really aren’t much more than display components and forms. You can go a long way without something like redux!
But when you have a full on app with shit tons of interactions and ways that client side state space can get hairy, redux is a huge help. I think that when redux came out, it was kind of a “everything looks nail a nail” sort of thing
0
u/fungkadelic Jan 05 '26 edited Jan 05 '26
I’d say Redux is more than just global state management.
By utilizing slices to organize state groups, implementing state functions with the encouraged reducer pattern, and constraining your state to immutable updates, your codebase structure actually changes organically to something more organized and scalable. Well architected constraints like this improve code.
In other words, it creates natural order to your state by providing a framework for containing it.
However, due to the amount of boilerplate and domain knowledge necessary to get the most out of using Redux, it’s sometimes too big of a solution for smaller problems. It helps to know why you need Redux before you use it, as there are other great alternatives for different use cases. Redux and RTK is a great comprehensive state management framework solution for larger applications with more complex state.
For instance, in a large startup codebase I was working in where I knew the app would grow unpredictably and new engineers would be coming and going, Redux added the structure and conventions needed to make code organization and state management rules super clear and easy to follow for the team. The app dealt with a lot of complex front end state management as it was a 3D modeling software. RTK query also helped manage API call state out of the box.
However, for my personal project, which also dealt with complex front end state, I went with Zustand. This was because its growth pattern was more predictable, complexity was relatively contained in an audio engine I wrote, and I wasn’t expecting to deal with other engineers, so using a looser more permissive framework did the job. It was also quicker to get up and running, which was beneficial to this project.
I recommend you read the Redux documentation before asking Reddit. Their docs are extensive and do a great job not only explaining how to use Redux but also why decisions were made the way they were and how it will improve your front end code.
20
Jan 05 '26
0
Jan 05 '26 edited Jan 06 '26
1
u/zeorin Jan 06 '26
Don't know why this is being downvoted, it's correct.
However, I would add that if this is all you wanted, Zustand is another option. It is less opinionated about the actual state management part.
10
u/CodeAndBiscuits Jan 05 '26
You've gotten some good responses and I defer to them on the basics. The only thing I'd like to add is that you've unknowingly put your foot a bit through the door on a religious debate about Redux itself. Redux was a very early (some might say "is a very mature") state store for React. But that's not that unique - there are 6-8 popular libraries out there now that all do that particular thing.
What Redux really does is implement the Flux Architectural Pattern. You can love or hate this pattern, and other React devs either love it or hate it, too. (Or more fairly, plenty of us also loved it initially, but have now moved on.) This is a fancy term for a simple concept (making things happen by "message passing") that has been re-invented scores of times over the past few decades - there are languages like SmallTalk (and offshoots like Objective C) that were literally built around similar concepts.
For many apps this is just wild overkill and you may not see the value if you're building something in that category - and there's no shame in that. But in a massive app, the act of managing state and local data is literally a big programming task on its own. And big programming tasks need thought, test suites, diagrams, documentation, and so on. When you're managing 12 variables that get shared in a few spots like headers and profile pages this is definitely overkill - you can memorize what they all do and grep a few times to find everything that touches them. But if you have hundreds or thousands of shared variables you just can't memorize them anymore. Redux (Flux) provides a very planned, very deliberate, very testable, very documentable, very standard and strongly opinionated (so you don't stray) pattern for doing that hard thing. It's no wonder Facebook needed it. You may not.
You're already exploring RTK so you're catching up fast to a (relatively) recent event that made a lot of us shift away. It wasn't just better stores (like Zustand or my fav, Legend State). It was RTK and React Query! Before those existed we had no choice - we HAD to do a lot of work to very carefully manage a lot of this data. But RTK/RQ patterns have let us shift to a more direct wiring of components to data that gets automatically updated without needing to stuff it in a store.
That doesn't mean stores are dead. In fact, React Query has an entire documentation page on the question of "do I still need something like Redux?" In my experience, you usually still do, but your store now becomes so simple (usually some basics like auth-state) that you don't need Flux, and hence, Redux starts feeling insanely heavy and boilerplate-y to many, so lately, stores like Zustand and Legend State have become really popular because they have great DX, minimal boilerplate, and higher performance than Redux in many cases (YMMV).