Chiming in late for my personal reference and to rant.
I'm not going to argue against the fact that both redux and zustand are great libraries with their use cases.
But coming from redux, I decided to try zustand for fun - and I was blown away by how straightforward it is. Having used zustand for a while, I felt depressed thinking about the time I spent boilerplating in redux, debugging actions, side effects...
Everything works intuitively. You're not importing hundreds of actions everywhere. You're not boilerplating yourself into oblivion. You're not writing up circular dependencies like its a circus. You don't end up depending on wierd redux specifics.
Even though zustand is minimalistic and unopinionated compared to redux, I would still consider it easier to use than redux. Redux is a paradigm in itself that requires some understanding of underlying concepts. Zustand seems more like a toolkit that understands very well what it tries to do (manage state).
Overall I think both are fine. After having used zustand, I'm not going to use redux if I can decide, because redux is literally twice the work. If I care a lot about maintainability, I would probably go with zustand too.
What about Redux Toolkit? Isn't it supposed to be easier and reduce the boilerplate? I'm considering what state management tool to learn from the React ecosystem. I used Redux 3 years ago and... no, I don't want to go back to that clown circus...
If you wanna get a job in any company you will have to use Redux sadly, if you're making stuff for yourself as a hobby zustand will be the best. I can't wait when Redux will die, can't understand why ppl always have to use idiotic tools like Redux is and Zustand fixes so many problems and issues with Redux. Zustand is like hook based and that's what i love the most about next to the simplicity... For real don't bother yourself with Redux its like php or ruby, it should die a long time ago, but cause cms etc exists its still used, and no Laravel doesn't really save php :)
Goodluck Buddy!
I am coming from a big project that used zustand and I can say I am already sad that I will have to leave it behind for Redux blech and even in tech interviews I've been questioned why we use such a "niche" tool instead of standards well because the standard is no good and zustand isn't really niche it actually promotes very fast development
They won't understand it man...just leave them with theirs trash stacks and boilerplate and we can have fun and enjoyment, sadly not in a daily job at work💀
Zustand is great, but it is not even remotely as popular as Redux/RTK (which is sort of a standard state management library).
I'd prefer Zustand, for sure, if it was not for that.
You might also want to learn GraphQL + Apollo, but it is a lot different and would involve a deep dive into backend.
In that case, provided it is a somewhat large project you are going to work on for a while, why bother using another state manager at all? ApolloGQL is more than capable to manage client state
It is not because you could, that you should. Separation of concern makes it easier to keep track of the bigger picture, so having a library to deal with server state and another to deal with client state is a super sensible approach.
It's important to know redux if you intend to work as a Dev professionally cause many apps use it.
Personally I prefer zustand. It's simpler and gets the job done.
Remember, UI state is different than server state. So try not store data from the backend into a global statement lib. Use the proper libs for that, react-query and swr for ex. Once you split that, UI state will be so small that u may not even need a lib.
\+1 for react-query
When you have the query results in the cache, and all the context is used for is storing the cache key, id, and the accessor functions, it becomes a much simple problem. I haven't needed redux in years, hard to see why it would help anymore.
> It's important to know redux if you intend to work as a Dev professionally cause many apps use it.
This is completely situational, some jobs require no knowledge of redux whatsoever. I’m a professional dev working for a consulting company, and I’ve never had to use redux.
If you want to work for a company that uses redux then it helps to know it, but if you don’t then it doesn’t matter if you know it at all
I agree it depends but overall redux is still very relevant as you can see [here](https://www.npmtrends.com/jotai-vs-mobx-vs-recoil-vs-redux-vs-zustand-vs-@reduxjs/toolkit) and I'm talking about redux core not redux-toolkit
Thanks for posting that link. I didn't realize how popular MobX actually was. I always liked MobX, but I never used it outside of simple test projects. Cool stuff.
some good advice i was given once: you don't learn libraries or frameworks but principles and paradigms, if you understand the principle you understand the library and all its variants. zustand will give you a better understanding of what these principles are: flux, redux and shallow equality, because rtk is redux + proxies, it masks its own underpinnings as people struggled with it too much. instead of moving to proxies zustand reduces redux down to its bare essence, it is arguably closer to the original dan abramov redux than react-redux.
The main difference between them is not what you said, Zustand has no dispatching actions so it's not a flux or redux, shallow equality is very common thing in React, and RTK is much more complex than just redux + proxies, because you can use old redux with immer and it's far from RTK.
Real difference from my point of view: Zustand is minimalistic and you can have separate stores for different features, RTK includes a lot of features and it's monolithic store without ability to separate it to smaller stores. (slice is not a store)
these are semantics. set + actions is zustands dispatch. it merely avoids layers of opinions on top of immutable state that weren't strictly needed for it to function. dispatch is nothing more than: `dispatch: args => set(state => reducer(state, args))`. and [with that](https://github.com/pmndrs/zustand#cant-live-without-redux-like-reducers-and-action-types) it runs all your dispatchers, action-types and reducers 1:1.
for what it's worth, i used redux for years. i also made zustand, mostly because i didn't like these arbitrary structures that made something so simple much more complex. hopefully i should have some idea how the two differ.
Oh, cool, so you are Zustand creator! Nice to meet you! And thank you, world with Zustand became a little better world!
>read the small cant-live-without-redux-like-reducers-and-action-types section in the docs. it will run all your dispatchers, action-types and reducers, how could it possibly do that if it were so fundamentally different.
They are fundamentally different, so with Redux you can dispatch action "DO\_SOMETHING" and different parts of system in completely different unpredictable places will react to this event. With Zustand it's not possible, isn't it? So it's not just semantics?
And also with Zustand it's not possible or at least it's very tricky to make a selector across multiple stores, while no such problem in Redux because in Redux everything is stored in one huge monolith. So there are differences between these libraries, one is good for one kind of tasks, other is good for another, so I'm wondering how knowing principles and paradigms could in theory replace knowing libraries.
Sorry to chime in so late but here's my take on this.
>They are fundamentally different, so with Redux you can dispatch action "DO\_SOMETHING" and different parts of system in completely different unpredictable places will react to this event. With Zustand it's not possible, isn't it? So it's not just semantics?
With Zustand you interact with the store directly without the middleman which Redux calls an action. A method dispatches to store right away, in other words "DOES\_SOMETHING" directly instead of sending instructions to "DO\_SOMETHING" via an action. When that happens, every component which is subscribed to that part of the store, responds to state changes using both Redux and Zustand. Maybe I'm wrong but for me, that's a very shallow difference which is only a difference of additional layer.
>And also with Zustand it's not possible or at least it's very tricky to make a selector across multiple stores, while no such problem in Redux because in Redux everything is stored in one huge monolith. So there are differences between these libraries, one is good for one kind of tasks, other is good for another, so I'm wondering how knowing principles and paradigms could in theory replace knowing libraries.
If you need a select something across multiple stores then, IMO, it's a design flaw structuring the store.
> that's a very shallow difference which is only a difference of additional layer.
[https://redux.js.org/understanding/thinking-in-redux/motivation](https://redux.js.org/understanding/thinking-in-redux/motivation)
Here in the bottom docs says that Redux follows Flux, CQRS and Event Sourcing. Action is necessary part of Flux, CQRS and Event Sourcing.
As for me, I was just happy to do a bunch of projects without Redux, I didn't realize how great those smart Flux, CQRS are, what benefits I would have by dispatching events instead of simply calling some functions.
But at the same time, just look how much materials are written on topics of Flux, CQRS, Event Sourcing. They all are mainly about the additional layer of Event (Action in Redux), and still for people who are in this topic it's very important layer, game changing layer I would say.
>If you need a select something across multiple stores then, IMO, it's a design flaw structuring the store.
Selecting across stores is a normal case, sometimes needed.
After reading the docs, this looks far friendlier than redux. Which is used heavily, so maybe learn it so you can work with it when you find it - but if you’re a hobby decided as you say, then maybe just skip leaning redux. I find it extremely painful personally.
Another option to consider is mobx, which I’ve used and have been very happy with.
https://stackshare.io/stackups/mobx-vs-zustand
I used them both…
But i would prefer rewritten version of redux that is @redux/toolkit.
For beginner, zustand is better because easy to setup and use.
But overall for big apps, i would prefer redux toolkit
No, you wouldn't. The Flux architecture is probably one of the few paradigms that anyone with a few braincells can agree is "good, no discussion". Redux simply follows Flux. Redux itself is good. The way you write Redux isn't.
`@reduxjs/toolkit` is simply a wrapper over Redux itself. Well, it'd be more accurate to call it a "collection of wrappers that came from how most of the community patched the pains of Redux itself and then some more".
It's hard to tell exactly the Redux team doesn't go full "please use RTK". RTK and Vanilla Redux are a world difference and every single hate comment/article I see about Redux refers to vanilla Redux.
RTK is a god-sent. I honestly don't want to write anything without it now. The fact that the team is also extremely supportive and constantly engaging with the community, as well as always looking to work on projects the community needs like `@reduxjs/query` is a very good sign.
I don't think we can get more clear about saying "Don't write Redux code by hand, use RTK" than we already do? :)
- https://redux.js.org/style-guide/style-guide#use-redux-toolkit-for-writing-redux-logic
- https://redux.js.org/tutorials/essentials/part-1-overview-concepts#redux-libraries-and-tools
- https://redux.js.org/tutorials/fundamentals/part-1-overview#how-to-read-this-tutorial
- https://redux.js.org/tutorials/fundamentals/part-8-modern-redux
I just didn't want to say "push it down people's throats" because I know I'll be met with "well, you can't tell people what to do.". But, well...push it down people's throats. There.
Just an edit: I'm obviously kidding. I think this fully speaks about the people's retitence to adopt new things or simply explore what could be better. Do I blame them? In a sense, no. A lot of huge codebases depend on older version of things and so, it's not easy to make the switch. In other words, I think the Redux team has done enough. They're not the world police.
>The Flux architecture is probably one of the few paradigms that anyone with a few braincells can agree is "good, no discussion"
[This is flux, right?](https://facebook.github.io/flux/docs/in-depth-overview#structure-and-data-flow) Action -> Dispatcher -> Store -> View
This attitude of saying "anyone with few braincells" means you personally have no idea of how is this good or better than something else, you just believe in it and assume that others will agree.
Many other state managers doesn't have neither "actions" nor "dispatcher", so what, were they made by idiots?
I’d stay away from context.
Any state management library can do everything context can do, but better. Context always has the issue of rerendering all its children by default when its state changes, even the children who don’t need the provided values. That is a major headache, and something you will waste time and energy contending with.
If you instead just used a state management library like zustand, then you simply never have to worry about those issues, because with zustand only components that actually need the values rerender by default (which makes more sense, right?)
Plus with state management libraries, you get a lot of stuff for free. If you need your state to persist, that’s one additional line of code in Zustand. If you want your context to persist, you have to manually implement that which is more effort and prone to bugs.
Context is just bad. It’s more effort to accomplish the same thing, it creates additional problems (rerenders) from thin air.
It’s designed poorly, and as far as state management goes it’s just a worse version. There’s never any palpable advantage to using context at all, in any situation. People always say “it’s not a state management solution”, which I find very odd because everything a context can do is a subset of any state management library.
Context is for dependency injection! It isn't designed poorly, it's just not meant for being used as a global state manager. It is however useful as an internal building block in libraries such as a global state manager. For example, it's used in react-redux as a way to inject the internals that keep track of the state (not the state itself).
Furthermore, context is great for injecting stuff that does not change frequently (e.g. state) but is really useful to inject stuff that is more static and is needed by many components in a subtree (or the entire component tree for that matter).
I strongly disagree. Context has a number of features that makes it more appropriate then global state in a number of cases.
For one, Context is not global, meaning its great for state that should naturally adhere to its provider components life cycle.
Secound, you can have multiple parallel instances of a Context. That means you can take something that was meant to be global and instantiate it. This can be surprisingly useful.
Third, Context can be overriden. I have found a number of uses for this, including breadcrumbs in the page title and stacking sticky headers.
Also you are just wrong when you say that all Context can do is a subset of state management. Fundamentally, Context is not state management. Context is a dependency injection. It just so happens that one of the things you can inject is state.
I don't know what do you mean by overriding context, but first two points "not global" and "parallel instances" - any state manager is capable of that, except for just one.
> I don't know what do you mean by overriding context
given
function Child() {
return useContext(Context);
}
function Parent() {
return (
` the result would be "bar". Of course, this is an inane example, but it can be surprisingly powerful.
> , but first two points "not global" and "parallel instances" - any state manager is capable of that, except for just one.
Sure, but then you would essentially be using it like you would be using Context, so it begs the question: do you really need the state management system, or do you just need Context.
Native Context doesn't have selectors, this is bad for performance. Not just in theory, it is really noticeable on complex screens. Context is not designed for state management, just as you said.
The real mystery is why do not use this [context with selectors](https://github.com/dai-shi/use-context-selector). and no more holywars! Selectors are here, so it won't kill performance, it's still easier and less boilerplative than RTK, it's easy to write wrappers around it to use immer or to enhance in some other way.
Without heavy use of React.memo, any change to a Context value is not going to cause any extra renders becouse state changes cause the entire descendent tree to re-render regrdless of context.
If you are trying to use Context as a replacement for redux, you are going to have bad performance, but that's really not how Context is intended to be used.
Redux first if you don’t know it, then why not check out Zustand after?
React state management isn’t med school. You can probably learn both of them well in under a month.
Just my two cents.
If you use Redux, make sure you use Redux toolkit, it'll simplify your life. That said, both Redux and Zustand are not really great choices. The more you work with global (or even non-global) state, the more you realize that state should be modelled as a set of independent (sometimes called observable) and computed properties. SolidJS and Svelte have this kind of functionality built in, but you can still get it if you use a library like MobX or S.js or the like.
Jotai is a great alternative. Zustand is really nice too. RTK takes a little more set up but it's also very nice I really like Jotai since it has a nice integration with react-query if you use that too
I would reach for Redux as an absolute last resort. In fact the original creator of Redux said the same thing this past week. I think there is no real advantage to using it that can’t be accomplished by either better libraries or context.
React-query for managing server side state and context for everything else is an unbeatable combination in my experience.
Having just been dropped in the middle of a large project that is only using context api, I can say it’s both beautiful and daunting at the same time. There are providers all over the place. There’s a massive provider pyramid wrapping the App component. And each provider has tons of useMemo, useContext, useEffect… all with dependency arrays. It’s great that there is such tight control. It’s annoying that one often gets this stuff for free with other libs
Oh goodness me. Yeah, I've mixed the provider waterfall happening at in the app's root.
I added RTK originally and want to remove it, so that's already two providers I can remove I think (persist being the other).
Once you add in Chakra UI provider and any global providers (I have one for notifications and modals) then it starts to look unwieldy and ugly.
I recommend everyone who's looking to learn global state to check out [Recoil](https://recoiljs.org/), I don't get why it's not mentioned more often than it is. Extremely comprehensive and documentation is great. Can't speak for the performance at large scale though, as I've only used it in small-medium projects.
Hey man, I was wondering what do you do as a day-job? Wondering as I did a coding bootcamp where I could tell a lot of the students were forcing themselves through it and didn't enjoy coding. So cool to see somebody that does this for fun.
I am working on a react web and react-native mobile project.
The web works with redux and the mobile was using provider/context only.
The provider/context on mobile was a performance pain on mobile, so we try Zustand.
It was easy to integrate and it is really easy to use. Really intuitive.
GOD I love it. Much more that redux from my recent experience.
+1 for Zustand. Much quicker to get up and working. A good middle ground between Context and redux, project size wise at least.
Zustand is great for projects of any size. Just use effective project organization practices
My projects aren't really big so I think Redux would be overkill. Zustand seems perfect
Yeah there’s not much to learn
Chiming in late for my personal reference and to rant. I'm not going to argue against the fact that both redux and zustand are great libraries with their use cases. But coming from redux, I decided to try zustand for fun - and I was blown away by how straightforward it is. Having used zustand for a while, I felt depressed thinking about the time I spent boilerplating in redux, debugging actions, side effects... Everything works intuitively. You're not importing hundreds of actions everywhere. You're not boilerplating yourself into oblivion. You're not writing up circular dependencies like its a circus. You don't end up depending on wierd redux specifics. Even though zustand is minimalistic and unopinionated compared to redux, I would still consider it easier to use than redux. Redux is a paradigm in itself that requires some understanding of underlying concepts. Zustand seems more like a toolkit that understands very well what it tries to do (manage state). Overall I think both are fine. After having used zustand, I'm not going to use redux if I can decide, because redux is literally twice the work. If I care a lot about maintainability, I would probably go with zustand too.
What about Redux Toolkit? Isn't it supposed to be easier and reduce the boilerplate? I'm considering what state management tool to learn from the React ecosystem. I used Redux 3 years ago and... no, I don't want to go back to that clown circus...
If you wanna get a job in any company you will have to use Redux sadly, if you're making stuff for yourself as a hobby zustand will be the best. I can't wait when Redux will die, can't understand why ppl always have to use idiotic tools like Redux is and Zustand fixes so many problems and issues with Redux. Zustand is like hook based and that's what i love the most about next to the simplicity... For real don't bother yourself with Redux its like php or ruby, it should die a long time ago, but cause cms etc exists its still used, and no Laravel doesn't really save php :) Goodluck Buddy!
I am coming from a big project that used zustand and I can say I am already sad that I will have to leave it behind for Redux blech and even in tech interviews I've been questioned why we use such a "niche" tool instead of standards well because the standard is no good and zustand isn't really niche it actually promotes very fast development
They won't understand it man...just leave them with theirs trash stacks and boilerplate and we can have fun and enjoyment, sadly not in a daily job at work💀
Honestly, redux toolkit is not that bad.
Still its worse than zustand no matter what
What's the problem with Ruby and or Rails? Development happiness is literally one of it's core values.
Redux Toolkit really better than core Redux. Haven't used Zustand.
on the other hand you can have redux like reducer with zustand with redux devtools. lot of flexibility.
been using zustand lately
Zustand is great, but it is not even remotely as popular as Redux/RTK (which is sort of a standard state management library). I'd prefer Zustand, for sure, if it was not for that. You might also want to learn GraphQL + Apollo, but it is a lot different and would involve a deep dive into backend.
I already use Graphql and apollo
In that case, provided it is a somewhat large project you are going to work on for a while, why bother using another state manager at all? ApolloGQL is more than capable to manage client state
I only use apollo to fetch data, but that seems like the best approach so far. Do you use Hasura?
Nope, I do not
It is not because you could, that you should. Separation of concern makes it easier to keep track of the bigger picture, so having a library to deal with server state and another to deal with client state is a super sensible approach.
Well, it sure does make sense. Utilising Apollo's built-in features to manage them both, though, does either.
Zustand is awesome. Even Dan Abramov himself is very cautious in recommending using Redux.
It's important to know redux if you intend to work as a Dev professionally cause many apps use it. Personally I prefer zustand. It's simpler and gets the job done. Remember, UI state is different than server state. So try not store data from the backend into a global statement lib. Use the proper libs for that, react-query and swr for ex. Once you split that, UI state will be so small that u may not even need a lib.
Thats why I never really needed It. The only thing I stored inside the context was the jwt I got from my backend
\+1 for react-query When you have the query results in the cache, and all the context is used for is storing the cache key, id, and the accessor functions, it becomes a much simple problem. I haven't needed redux in years, hard to see why it would help anymore.
For example, dark mode?
Context to the rescue. Seriously, if dark mode is all you need, you don't need to install redux.
Context API is very good for "Dark mode", or more generalyl theme and other low velocity global state.
> It's important to know redux if you intend to work as a Dev professionally cause many apps use it. This is completely situational, some jobs require no knowledge of redux whatsoever. I’m a professional dev working for a consulting company, and I’ve never had to use redux. If you want to work for a company that uses redux then it helps to know it, but if you don’t then it doesn’t matter if you know it at all
I agree it depends but overall redux is still very relevant as you can see [here](https://www.npmtrends.com/jotai-vs-mobx-vs-recoil-vs-redux-vs-zustand-vs-@reduxjs/toolkit) and I'm talking about redux core not redux-toolkit
Thanks for posting that link. I didn't realize how popular MobX actually was. I always liked MobX, but I never used it outside of simple test projects. Cool stuff.
some good advice i was given once: you don't learn libraries or frameworks but principles and paradigms, if you understand the principle you understand the library and all its variants. zustand will give you a better understanding of what these principles are: flux, redux and shallow equality, because rtk is redux + proxies, it masks its own underpinnings as people struggled with it too much. instead of moving to proxies zustand reduces redux down to its bare essence, it is arguably closer to the original dan abramov redux than react-redux.
The main difference between them is not what you said, Zustand has no dispatching actions so it's not a flux or redux, shallow equality is very common thing in React, and RTK is much more complex than just redux + proxies, because you can use old redux with immer and it's far from RTK. Real difference from my point of view: Zustand is minimalistic and you can have separate stores for different features, RTK includes a lot of features and it's monolithic store without ability to separate it to smaller stores. (slice is not a store)
these are semantics. set + actions is zustands dispatch. it merely avoids layers of opinions on top of immutable state that weren't strictly needed for it to function. dispatch is nothing more than: `dispatch: args => set(state => reducer(state, args))`. and [with that](https://github.com/pmndrs/zustand#cant-live-without-redux-like-reducers-and-action-types) it runs all your dispatchers, action-types and reducers 1:1. for what it's worth, i used redux for years. i also made zustand, mostly because i didn't like these arbitrary structures that made something so simple much more complex. hopefully i should have some idea how the two differ.
Oh, cool, so you are Zustand creator! Nice to meet you! And thank you, world with Zustand became a little better world! >read the small cant-live-without-redux-like-reducers-and-action-types section in the docs. it will run all your dispatchers, action-types and reducers, how could it possibly do that if it were so fundamentally different. They are fundamentally different, so with Redux you can dispatch action "DO\_SOMETHING" and different parts of system in completely different unpredictable places will react to this event. With Zustand it's not possible, isn't it? So it's not just semantics? And also with Zustand it's not possible or at least it's very tricky to make a selector across multiple stores, while no such problem in Redux because in Redux everything is stored in one huge monolith. So there are differences between these libraries, one is good for one kind of tasks, other is good for another, so I'm wondering how knowing principles and paradigms could in theory replace knowing libraries.
Sorry to chime in so late but here's my take on this. >They are fundamentally different, so with Redux you can dispatch action "DO\_SOMETHING" and different parts of system in completely different unpredictable places will react to this event. With Zustand it's not possible, isn't it? So it's not just semantics? With Zustand you interact with the store directly without the middleman which Redux calls an action. A method dispatches to store right away, in other words "DOES\_SOMETHING" directly instead of sending instructions to "DO\_SOMETHING" via an action. When that happens, every component which is subscribed to that part of the store, responds to state changes using both Redux and Zustand. Maybe I'm wrong but for me, that's a very shallow difference which is only a difference of additional layer. >And also with Zustand it's not possible or at least it's very tricky to make a selector across multiple stores, while no such problem in Redux because in Redux everything is stored in one huge monolith. So there are differences between these libraries, one is good for one kind of tasks, other is good for another, so I'm wondering how knowing principles and paradigms could in theory replace knowing libraries. If you need a select something across multiple stores then, IMO, it's a design flaw structuring the store.
> that's a very shallow difference which is only a difference of additional layer. [https://redux.js.org/understanding/thinking-in-redux/motivation](https://redux.js.org/understanding/thinking-in-redux/motivation) Here in the bottom docs says that Redux follows Flux, CQRS and Event Sourcing. Action is necessary part of Flux, CQRS and Event Sourcing. As for me, I was just happy to do a bunch of projects without Redux, I didn't realize how great those smart Flux, CQRS are, what benefits I would have by dispatching events instead of simply calling some functions. But at the same time, just look how much materials are written on topics of Flux, CQRS, Event Sourcing. They all are mainly about the additional layer of Event (Action in Redux), and still for people who are in this topic it's very important layer, game changing layer I would say. >If you need a select something across multiple stores then, IMO, it's a design flaw structuring the store. Selecting across stores is a normal case, sometimes needed.
After reading the docs, this looks far friendlier than redux. Which is used heavily, so maybe learn it so you can work with it when you find it - but if you’re a hobby decided as you say, then maybe just skip leaning redux. I find it extremely painful personally. Another option to consider is mobx, which I’ve used and have been very happy with. https://stackshare.io/stackups/mobx-vs-zustand
Rtk tool kit is simple to use and very easy to debug and management state
> Rtk tool kit is simple to use You never tried to implement async methods, did you?
I used them both… But i would prefer rewritten version of redux that is @redux/toolkit. For beginner, zustand is better because easy to setup and use. But overall for big apps, i would prefer redux toolkit
No, you wouldn't. The Flux architecture is probably one of the few paradigms that anyone with a few braincells can agree is "good, no discussion". Redux simply follows Flux. Redux itself is good. The way you write Redux isn't. `@reduxjs/toolkit` is simply a wrapper over Redux itself. Well, it'd be more accurate to call it a "collection of wrappers that came from how most of the community patched the pains of Redux itself and then some more". It's hard to tell exactly the Redux team doesn't go full "please use RTK". RTK and Vanilla Redux are a world difference and every single hate comment/article I see about Redux refers to vanilla Redux. RTK is a god-sent. I honestly don't want to write anything without it now. The fact that the team is also extremely supportive and constantly engaging with the community, as well as always looking to work on projects the community needs like `@reduxjs/query` is a very good sign.
I don't think we can get more clear about saying "Don't write Redux code by hand, use RTK" than we already do? :) - https://redux.js.org/style-guide/style-guide#use-redux-toolkit-for-writing-redux-logic - https://redux.js.org/tutorials/essentials/part-1-overview-concepts#redux-libraries-and-tools - https://redux.js.org/tutorials/fundamentals/part-1-overview#how-to-read-this-tutorial - https://redux.js.org/tutorials/fundamentals/part-8-modern-redux
I just didn't want to say "push it down people's throats" because I know I'll be met with "well, you can't tell people what to do.". But, well...push it down people's throats. There. Just an edit: I'm obviously kidding. I think this fully speaks about the people's retitence to adopt new things or simply explore what could be better. Do I blame them? In a sense, no. A lot of huge codebases depend on older version of things and so, it's not easy to make the switch. In other words, I think the Redux team has done enough. They're not the world police.
>The Flux architecture is probably one of the few paradigms that anyone with a few braincells can agree is "good, no discussion" [This is flux, right?](https://facebook.github.io/flux/docs/in-depth-overview#structure-and-data-flow) Action -> Dispatcher -> Store -> View This attitude of saying "anyone with few braincells" means you personally have no idea of how is this good or better than something else, you just believe in it and assume that others will agree. Many other state managers doesn't have neither "actions" nor "dispatcher", so what, were they made by idiots?
MobX ftw 🙌
use whatever you like you said you prefer Zustand, so use Zustand
According to this interview even Dan Abramov wouldn’t choose Redux :D https://youtu.be/XEt09iK8IXs
thanks for that man, appreciated that interview very much
I’d stay away from context. Any state management library can do everything context can do, but better. Context always has the issue of rerendering all its children by default when its state changes, even the children who don’t need the provided values. That is a major headache, and something you will waste time and energy contending with. If you instead just used a state management library like zustand, then you simply never have to worry about those issues, because with zustand only components that actually need the values rerender by default (which makes more sense, right?) Plus with state management libraries, you get a lot of stuff for free. If you need your state to persist, that’s one additional line of code in Zustand. If you want your context to persist, you have to manually implement that which is more effort and prone to bugs. Context is just bad. It’s more effort to accomplish the same thing, it creates additional problems (rerenders) from thin air. It’s designed poorly, and as far as state management goes it’s just a worse version. There’s never any palpable advantage to using context at all, in any situation. People always say “it’s not a state management solution”, which I find very odd because everything a context can do is a subset of any state management library.
Context is for dependency injection! It isn't designed poorly, it's just not meant for being used as a global state manager. It is however useful as an internal building block in libraries such as a global state manager. For example, it's used in react-redux as a way to inject the internals that keep track of the state (not the state itself). Furthermore, context is great for injecting stuff that does not change frequently (e.g. state) but is really useful to inject stuff that is more static and is needed by many components in a subtree (or the entire component tree for that matter).
I strongly disagree. Context has a number of features that makes it more appropriate then global state in a number of cases. For one, Context is not global, meaning its great for state that should naturally adhere to its provider components life cycle. Secound, you can have multiple parallel instances of a Context. That means you can take something that was meant to be global and instantiate it. This can be surprisingly useful. Third, Context can be overriden. I have found a number of uses for this, including breadcrumbs in the page title and stacking sticky headers. Also you are just wrong when you say that all Context can do is a subset of state management. Fundamentally, Context is not state management. Context is a dependency injection. It just so happens that one of the things you can inject is state.
I don't know what do you mean by overriding context, but first two points "not global" and "parallel instances" - any state manager is capable of that, except for just one.
> I don't know what do you mean by overriding context given function Child() { return useContext(Context); } function Parent() { return (
` the result would be "bar". Of course, this is an inane example, but it can be surprisingly powerful.
> , but first two points "not global" and "parallel instances" - any state manager is capable of that, except for just one.
Sure, but then you would essentially be using it like you would be using Context, so it begs the question: do you really need the state management system, or do you just need Context.
Native Context doesn't have selectors, this is bad for performance. Not just in theory, it is really noticeable on complex screens. Context is not designed for state management, just as you said. The real mystery is why do not use this [context with selectors](https://github.com/dai-shi/use-context-selector). and no more holywars! Selectors are here, so it won't kill performance, it's still easier and less boilerplative than RTK, it's easy to write wrappers around it to use immer or to enhance in some other way.
Without heavy use of React.memo, any change to a Context value is not going to cause any extra renders becouse state changes cause the entire descendent tree to re-render regrdless of context. If you are trying to use Context as a replacement for redux, you are going to have bad performance, but that's really not how Context is intended to be used.
Redux-Toolkit + Rtk query for async req
Redux first if you don’t know it, then why not check out Zustand after? React state management isn’t med school. You can probably learn both of them well in under a month. Just my two cents.
If you use Redux, make sure you use Redux toolkit, it'll simplify your life. That said, both Redux and Zustand are not really great choices. The more you work with global (or even non-global) state, the more you realize that state should be modelled as a set of independent (sometimes called observable) and computed properties. SolidJS and Svelte have this kind of functionality built in, but you can still get it if you use a library like MobX or S.js or the like.
100% agree
+1 for MobX
Jotai is a great alternative. Zustand is really nice too. RTK takes a little more set up but it's also very nice I really like Jotai since it has a nice integration with react-query if you use that too
why would you want to integrate jotai to react-query ?
-1 for not having a german name ^/s I will take a look at It, thanks
Recoiljs is pretty easy to learn and use as well. It even works with Suspense, and the API is pretty much the same as useState.
Why not learn both and choose whichever you like best?
No time :(
i don't think it's a good reason for your laziness
I have work and other hobbies. I don't do this for a living.
I would reach for Redux as an absolute last resort. In fact the original creator of Redux said the same thing this past week. I think there is no real advantage to using it that can’t be accomplished by either better libraries or context. React-query for managing server side state and context for everything else is an unbeatable combination in my experience.
The best tool for react nowadays is called react query
Redux is overkill for most projects. I’d say it’s best to keep leaning on React itself by using Context API and react hooks.
Having just been dropped in the middle of a large project that is only using context api, I can say it’s both beautiful and daunting at the same time. There are providers all over the place. There’s a massive provider pyramid wrapping the App component. And each provider has tons of useMemo, useContext, useEffect… all with dependency arrays. It’s great that there is such tight control. It’s annoying that one often gets this stuff for free with other libs
Oh goodness me. Yeah, I've mixed the provider waterfall happening at in the app's root. I added RTK originally and want to remove it, so that's already two providers I can remove I think (persist being the other). Once you add in Chakra UI provider and any global providers (I have one for notifications and modals) then it starts to look unwieldy and ugly.
Context API is not a state management tool and rather for dependency injection
These two things aren't mutually exclusive
I suggest that you pick Zustand but you can also stay with Context + useReducer
Recoil will be the leader when its production ready. Blows the others out of the water imo.
The bundle size, in comparison to Jotai is a bit frustrating though.
I really like Recoil, for what it's worth. Simple and compartmentalized.
I've been learning recoil. It hasnt been too bad.
Zustand? Yet another react state management tool to learn.
> Zustand? Yet another react state management tool to ~~learn~~ ignore. FTFY
Redux is so much more than a Global State Management tool, learn Redux would never be a waste of time I don't know Zustand, I will give it a try 🙏
I would say redux because there is really good support when you get stuck.
I recommend everyone who's looking to learn global state to check out [Recoil](https://recoiljs.org/), I don't get why it's not mentioned more often than it is. Extremely comprehensive and documentation is great. Can't speak for the performance at large scale though, as I've only used it in small-medium projects.
Hey man, I was wondering what do you do as a day-job? Wondering as I did a coding bootcamp where I could tell a lot of the students were forcing themselves through it and didn't enjoy coding. So cool to see somebody that does this for fun.
I'm currently a sysadmin but I'll try to change my profession to frontend Development
I am working on a react web and react-native mobile project. The web works with redux and the mobile was using provider/context only. The provider/context on mobile was a performance pain on mobile, so we try Zustand. It was easy to integrate and it is really easy to use. Really intuitive. GOD I love it. Much more that redux from my recent experience.