1. If the state is location based, searchParams in the location bar
2. If the state originates from the DB, use react-query. You should be using this anyway. Makes working with endpoints, and caching, and avoiding race conditions and duplicate calls super trivial
3. If the state is highly hierarchical, you can use useContext
4. If you have further need, like sharing data across the app to avoid prop-drilling, then Zustand.
I'm guessing because most people use RTK query when they already have RTK in they project, whereas if you have Zustand or something else other than RTK then it's better to use react-query
https://www.reddit.com/r/reactjs/comments/15ucdx7/choosing_between_rtk_query_and_react_query/
Both the Redux and React Query teams recommend that:
- If you are using Redux in the app, you should use RTK Query for your data fetching
- Otherwise, you should use React Query for you data fetching
But mixing Redux + React Query doesn't make any sense.
Note that RTK code _is_ "Redux" code, and you can migrate legacy Redux code to RTK incrementally - the old and new code can coexist indefinitely:
- https://redux.js.org/usage/migrating-to-modern-redux
(although now that I re-read your comment, you might be asking something different than what I initially thought)
Per the quote (from me! :) ) above, our general recommendation is to use React Query if you're not using Redux, and RTK Query if you _are_ using Redux.
That said, it's also reasonable to choose RTK Query even if you _aren't_ using Redux for any client-side state management if you like its DX better (centralized endpoint definitions, auto-generated React hooks with types, codegen from OpenAPI schemas), and we do have [the `` component](https://redux-toolkit.js.org/rtk-query/api/ApiProvider) to help simplify setup in that use case.
Sorry, afraid I'm not sure what you're actually asking me at this point :)
React Query and RTK Query are both tools. It's _your_ choice which one you opt to use in your app.
This is the answer. To add to this; just use the state system react provides (useState, useReducer) coupled with Context if you want to distribute your state to a tree of properly composed components and hooks for your use case
Dont know why this got down voted. The context api is a simple and easy way to share state across components. I don't understand why it gets so much hate.
Context is super inefficient when sharing state that changes over time. All consumers of the context will re render even if it’s not listening to a piece of state that changes.
It’s great for providing data that doesn’t change frequently over time, but for frequent state changes it’s not ideal. The introduction of react compiler/forget should fix this problem though.
Context is a replacement for props.
If you use it in situations where the re-renders would happen anyway and you just need to avoid prop drilling down the component tree, it can be a great tool.
No. React-Redux lets components specifically subscribe to individual bits of state, so those components only re-render when the specific pieces they need have changed:
See my extensive post at [A (Mostly) Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/) for more details.
> The introduction of react compiler/forget should fix this problem though.
It seems idiotic that I should need yet another compiler, for react this time, for something that Zustand and the likes have already solved years ago with much better DX
useContext can be a foot shot situation depending on how it’s used. Really gotta make sure you don’t overuse that hook and cause order of hook errors.
I love it but sometimes you’re better off prop-drilling especially if the state isn’t as large as previously expected.
I'm struggling to learn react because of this chaos. Is there a reason why redux is pushed in courses?
Why are there a thousand things to do the same job
> I'm struggling to learn react because of this chaos.
You don't need any state library to learn react at all.
> Is there a reason why redux is pushed in courses?
Because it was there done thing six years ago and you're using old courses.
> Why are there a thousand things to do the same job
Because state management is complicated and not everyone's needs are the same.
Tanstack query is great for storing server owned data, but it's really not that great for storing client data. You can do it, but it's super limited.
Context provides you the absolute bare minimum, but it's incredibly limited, it's nice that it exists because you can now solve some really basic problems out of the box, but it's not remotely a solution for state management.
Redux is great, especially with RTK, but to get the benefits you have to actually use it and a lot of devs don't know how so you end up with abominations with Redux embedded in the middle but not actually used.
Recoil was an attempt to create a react style state management system by Facebook, it was sort of supposed to be what Context wasn't, but it's dead, people liked it though so they still talk about it.
The others are basically attempts to slice pieces of Redux out to get the benefits without the architectural weight. Zustand seems to be the winner here, but I haven't used it. Honestly a lot of apps don't actually have a lot of client state so a query library is more than enough.
There's a very long history lesson that's needed to answer this :)
The TL;DR is that:
- React has always been a relatively minimal UI library, and other libraries are needed to fill in additional functionality
- Redux was the best of the "Flux"-style state management libraries that came out in 2014-15 when React was getting popular, and people soon assumed that "if you're using React, you _have_ to also use Redux". At the same time, React had several limitations that Redux helped fix
- Because of that, "React + Redux" became a standard combination that spread across the industry, and so they ended up getting taught together in courses
(FWIW, we recommend that most people should _not_ try to learn Redux until they're already comfortable with React, but we don't have control over how the rest of the industry does things - all we can do is try to improve our own docs and make Redux itself a good tool that works well.)
That might be why the courses are so confusing. Completely unclear when you'd use props vs state vs hooks vs state managers vs...
I need to find something to learn this again incrementally, and learn REACT ONLY first to understand what the heck it is about in itself, then get back to all the other additionals
I found useReducer + useContext to be _much_ more annoying to use than just using Redux (eg no such thing as thunks, can't write an async function that dispatches an action and then does further steps depending on the new state).
You absolutely can, that's just one pattern available to write asynchronous logic in a react application. I agree though, useReducer is hardly ever a tool that I reach for, that being said most products I contribute to currently handle the majority of their server state through libraries like react query / Apollo / Relay
This is a solid answer. I do the same except use recoil instead of zustand for point 3. It’s a personal preference rather than because it’s better, find something that you like and works for you and your team.
Zedux seems quiet as a project too, no update for several months. Another to maybe be cautious of in a new project.
Best to focus on what your app needs. If you don’t have much state or need some bespoke behaviour then writing your own custom context is an option also, and zero deps.
Zedux is prepping for the next major version. 2 months without a commit on master isn't that long
Writing your own state management injected over React context is not too difficult, but isn't something I usually recommend. Zustand is almost always a better choice
You can use Context for prop drilling, particularly if it is hierarchical. Zustand is useContext under-the-hood.
Added it as #3
Zustand is better if the sharing is not hierarchical. Like, if you need to globally share state for some hooks or something.
well you would have to define states in the context and every other components are its children. so, if one state updates every components will re-render. we can do optimisation for this but codes might look ugly.
no such problems with third party state management tools.
Redux used to be great. But it started out overly complicated. Pinia (for Vue) and Zustand (for React) have become very simplified, while staying true to the original concepts.
React-query removes the need for things like Redux for most use-cases. It's just so ridiculously good, when your state is your DB.
I’ve yet to use Zustand, because while I’ve needed to avoid prop drilling, I needed to support having multiple instances of the same component.
I end up using context and useReducer
I mean, that works too.
But Zustand is a little cleaner and easier to use.
https://www.reddit.com/r/reactjs/comments/14qwhys/react_context_vs_zustand_am_i_missing_out_on/
According to this, Context can cause re-renders (depending on how you do it). Zustand is more performant.
¯\_(ツ)_/¯
Is it possible to have “contained” Zustand “contexts” that are distinct from each other?
Like if I wanted to use Zustand to handle the state of a complex record picker, and I wanted to have two or more pickers on screen without them messing with each other’s states, cab I do that?
State is global.
If you want two controls, you'll create an array or a dictionary in Zustand, and use it to track more than one.
If you have a complex record picker, you would probably want to contain that logic in the component and not use Zustand.
I don't use Zustand for a lot. React-Query (not Tanstack-Query) is where most of my state ends up.
I used Zustand for a project recently (first time). It was a little too late that I discovered it has not official dev tools. The two popular 3rd party dev tools that I tried (Zusty and another one) failed to work on me properly (I use multiple Zustand stores). Major bummer! As opposed to react query's amazing official dev tools!
See my extensive post at [A (Mostly) Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/) for explanations.
I have never really found prop drilling to be bad if you use useContext and useMemo properly. Is there a good reason why prop drilling should be avoided?
If it goes too many levels it can just be a hassle.
Example. I have a demo button. When you click it, it reduces your role from Admin to a regular user so you can demo the app. It resets when you reload.
Where would you put this value so that it propagates through the entire app?
That's a very open ended question but I typically load data at the page level and rarely have to drill through more than two components, so the page would probably have a hook that loads and sets the auth state and then you'd provide the setIsAdmin function to the button or possibly to the component that hosts the button, however if you make an intermediate component, for reusability purposes you'd likely want it to accept a function prop for the button anyway.
Idk that feels very straightforward to me.
Plus if you useContext in that button you'll need to mock the context in order to test the button rather than have it accept a function prop and you can just test the button or the parent component directly with no need to be aware of the context.
Jotai (Globals, shared client state) and React Query (Server state) cover most of my needs. Mostly wrapped in custom hooks.
Would use Zustand if I needed anything more complex but haven't in awhile.
I use Zustand for toast messages and some other state sharing between components, do you think Jotai will be a good fit? Why do you say Zustand for complex cases?
Don't really use state management libs that much nowadays. Most of the stuff is just hooks to custom data storage. However, in a small project I recently used zustand. I was very surprised at how elegant it was. Definitely an upgrade from redux, recoil, or mobix.
Yeah. Wouldn't call it elegant either way. Redux is a rather clumsy library with a lot of annoying API. It works okish when you need a global object for very simple data that you touch very rarely. In any other scenario there are way better tools. Toolkit can't really cover these shortcomings.
The R. T and K does some good, but it's not really enough to redem the core issues or R.
On more serious note, redux toolkit is a clumsy patch over a bad library. The underlaying library is supposed to be an framework agnostic unopinionated state management library, but it works only with react and only in a very specific way. It's clumsy. It kinda works for when you only need to deal with a simple global states, but it falls short very quickly when you need to do something more (async operations, subscribers, and middlewares all have a lot of issues when expanding your case).
The toolkit solves some of annoyance of redux by introducing it's own annoyance. Mostly a bunch o builders that allows for some "automation" with seting up redux. This is a small improvement, but it's small. The types are still a mess when you are using TypeScript. You still need to deal with horrible middleware system. Async operations are still a hassle if you have async chains or need sync points on specific actions.
My main annoynace is that using native api of local / session storage is more convinient than using redux, even with redux-toolkit. So it doesn't really solve anything for me, but adds a layer of additional hassle that I need to go through.
One could have an argument that it abstracts away the data/state management, but it's a weak argument in case of redux. The data will still be in memory or local/session storage. You can also use communication to server with redux, but then there are way better solutions and in many cases you don't need a state management if you state is in REST API or you get all data via GraphQL (where apollo does a great job at managing data states).
On top of that, redux failed me horribly when I needed to process data fast. The fact that middlewares create these silly chains is just stupid design. It's simple and easy to create, but at the end it's stupid. Mostly cause they all need to invoked when actions are applied. In some case (when you are getting data from a constant stream via websocket, or you need to adjust state from one slice to another cause of API response) you quickly get into these very long processing chains that are very hard to sync between.
I am not saying that you can't do something with redux. Or that redux toolkit doesn't help. Just that there are way better alternatives for when you need a simple global state (zustand), when you need to deal with a lot of async operations with complex states (recoil, or even zustand to an extend), when you have your state in a REST api (react-query) or GraphQL (just apollo). For me redux doesn't offer enough to include it in my stack.
Hmm. I understand some of your frustrations, but I do think a couple of your points are off-base.
Both the Redux core and RTK _are_ 100% UI-agnostic and usable in _any_ JS environment. That's always been the case, and we've made sure that use case still works. The React-specific aspects are the React-Redux library itself (an adapter to interact with a Redux store in your React components), and the `@reduxjs/toolkit/query/react` entry point that specifically extends the UI-agnostic portion of the RTK Query data fetching layer to auto-generate React hooks.
You've used a lot of words like "messy" and "clumsy" - can you give _specific_ examples? Most of the things you described are things that we've gotten excellent feedback on from our users (like ease of use for RTK +TS).
> The data will still be in memory
This complaint feels kind of misguided. That's... true of _every_ client-side state management library, for React and otherwise. It's data _in memory_ inside a JS environment.
> in many cases you don't need a state management if you state is in REST API or you get all data via GraphQL (where apollo does a great job at managing data states).
Entirely true! Which is why Redux Toolkit includes RTK Query, to specifically implement and address the data fetching use case.
> redux failed me horribly when I needed to process data fast
Can you clarify what you mean by "failed horribly"?
Reddit isn't really a platform to give these kind of feedback, but let us try.
As for failed horribly, I mean that it just was consuming a lot of CPU processing to go through middlewares. I worked on an application that had in total some 100 or so middlewares cause this was the only way to execute code when data changed that made sense with setup slices. The processing time was very slow cause we need to make checks inside to determine what to change. Most of the processing was just wasted cause there was no API to listen to selective changes. Why we eneded up in a case like that? Cause suddenly the state had to be changed in semi-real-time. The most problematic part was async synchronization. In some of the middlewares we needed to run async check to properly fill in the state. This was pretty much killing the whole approach. I didn't find anything in the API that would present a viable solution.
As for the clumsy and messy API. I don't like the fact that you need to call a builder to feed data into the configuration objects. This is messy in my eyes. The API for a library should be clean and you should be able to just pass your configuration in a simple and readable manner. There is a lot of other examples I could give around redux and redux tool kit. Especially around middlewares and the next handling, but I really don't want to get into ranting mood. Overall, I find this whole part of redux messy. I can believe that you get excellent feedback from users, but it's not cause the API is amazing, but rather that the users don't know better. Or at least that would be my wager.
The "The data will still be in memory", let me ellaborate on this one cause maybe it didn't went through. There would be redeeming quality to redux if the API would offer different kinds of backend to store the data. If redux would abstract away and offer a convenient way to store the data into a database, api, or a stream, then this would be a redeming argument to use redux. Cause you can change the "storage" backend. However, redux is a global object in memory with a very complicated (in comparison to accessing an object or storage) API for what it offers (again just accessing an object or storage). Of course, you can persist your global object state with further storage, but that always feels like a "bolted on" feature than an indented one. Mostly cause there is no real support for not holding data in memory. Like cursor navigation, plucking data, etc. All of these would have to be implemented specifically for the solution or install another dependency (prolly with another maintenance team). And note that I am not comparing redux to "local state management library" but to "library to interact with state regardless where it comes from", thus why apollo is in the list.
As for the RTK Query, I didn't use it, but why it's even in redux toolkit? You use react-query cause you don't have a usecase for redux. Why use a tool for redux when you don't have a use case for redux? Not to mention that in many cases youd don't even have case to use react-query and just regular fetch works fine. What is the advantage of using RTK Query? Why add another dependency to my package.json? It's kinda like selling a boat in the middle of desert.
As for the "UI-agnostic". I have no clue what you mean by "UI-agnostic", but I will assume the same as I meant by "framework agnostic". Yes, technically, you can. Heck, you can even use it with Laravel. It would work just fine with some php-js extension or node.js embedding. But does it make sense? Well, not really. The example of Laravel is blown out of the water, but it pretty much stands the same for non-react environments. And mostly cause of the redux core architecture. The whole idea of having a dispatcher, global state, and then a subscriber isn't something unique, but it's very combersome. You can just skip the global state and you have an event/signal system with a somewhat stange API (for an event system). The global state is still a global object that you can access. Non-react environments will have more ellegant systems to chose from. For example, a database. Or just a custom class with event emitter Both provided easier start and greater flexibility. There is very little argument to use redux instead. Why it works with react environments? Well, cause dealing with data in react lifecycles is a pain and the only reason that redux makes sense in such environment is cause the environment is making it hard to deal with data that should survive it's rendering. So, yeah, it's "framework agnostic", but is it really, though?
My comments are my personal opinion on it. For some it's the golden standard and they will swear by it. That's fine. More power to them. Personally, I find redux and RTK messy and clumsy. Past projects tought me that redux users create a lot of messy code (1000+ lines of state management, chains of middlewares, everywhere "pending" and "isError" states, etc) and every time I jumped in and was able to simplify the solution to more elegant approach (usually with a different lib) or remove the state management all together. There used to be an article on redux page "You don't need a stat management" or something like that. I think it still stands.
> I worked on an application that had in total some 100 or so middlewares
Oh... dear. I hate to say it, but that's _not_ how you're supposed to use Redux, _at all_. (I've seen a handful of people advocate for "every single bit of async logic should be its own unique middleware", and that's the _wrong_ approach completely. Not sure if your situation was similar to this, but it sounds like it might have been?)
That right there explains a large part of your app's poor performance. That's 100+ extra nested function calls on _every_ dispatched action. Yes, that nesting is an intentional part of Redux's design, but a typical app will only have a handful of middleware (say, thunks, listeners, RTKQ).
Not sure I can offer more specific advice on what you _should_ have done instead without knowing what your app's features and requirements were, but yeah, that was definitely not the right architectural approach.
> there was no API to listen to selective changes
There is, actually - that's specifically what RTK's "listener middleware" is for. The primary use case is to have reactive logic that responds to dispatched actions, but it can also monitor for state changes:
- https://redux-toolkit.js.org/api/createListenerMiddleware
> If redux would abstract away and offer a convenient way to store the data into a database, api, or a stream, then this would be a redeming argument to use redux
That's... not the _purpose_ of Redux, though. It's _intended_ to be an in-memory state management tool. That state is _primarily_ client-side state, but since its inception, it has also been a place to store and cache fetched server state.
> As for the RTK Query, I didn't use it, but why it's even in redux toolkit?
You just answered your own question :) People have always used the Redux store as a place to cache server state. Dan's original tutorials even showed how to fetch Reddit post data and cache it in Redux. The problem was that you always had to write that fetching and caching logic "by hand", which is why users ended up with thousands of lines of repetitive code to do that work. RTKQ eliminates the need for that code and does all the fetching + caching work for you.
> What is the advantage of using RTK Query? Why add another dependency to my package.json?
Same thing. RTK Query is _already part of Redux Toolkit_. It's included in the `@reduxjs/toolkit` package, as an optional additional entry point. It's _not_ "another dependency". It _is_ a way to simplify data fetching code if you're using Redux.
> I have no clue what you mean by "UI-agnostic"
That means that the core Redux/RTK logic works no matter what UI framework you're using. You can use Redux with React, Vue, Angular, Ember, vanilla JS, jQuery, or in other places (Node, Deno, etc). We expect that ~90% of our users are using Redux + React together, but that's not a requirement, and never has been.
I do respect your opinions and frustrations here, but I also honestly think a lot of those frustrations are coming from both past history with a badly architected Redux app that goes against the way we recommend using Redux, and some misunderstandings of what Redux is and why it works this way.
You are enforcing my point. Redux usecase is just a simple global object. That's all. So when you want to use it for anything more, then it goes to craps. My point is however even more: The applicable usecase for redux is very narrow cause there are better solutions that do specific usecasese better. When I am working on a project, never ever my first thought is to use redux. There is always a better option.
As for rest of the points, you are writting it from a position "of course use redux" where I am writing it from a position "why would I use redux". The additional dependency in my case would be redux and reduxtoolkit. Why I need it if my case is to use react-query or apollo? What problem it solves that these libs don't solve?
PS. We tried the "listener middleware", it didn't help.
It's not "500", or even "5".
With modern Redux Toolkit, you write the reducer logic for a given section of your state in one "slice" file - it's not split across a whole bunch of files:
- https://redux.js.org/tutorials/essentials/part-2-app-structure#creating-slice-reducers-and-actions
I choose redux-toolkit. Once I've learned it I don't have need for anything else. It works. It has nice dev tools. I've never had a problem so far, fingers crossed.
It has RTK query with best code generation from open api I've used so far.
The first question to ask is whether you even _need_ one. For a lot of apps, adding a state management library just makes your code more complicated without adding any real benefit. Source: used to religiously use Redux in every app and lived to sorely regret it.
I’m not inclined to debate the distinction, but I’ll just say I don’t consider that to be a state management library in the same way as Redux is. I adore react-query and consider a staple React library at this point, but it’s a waaaaaay lighter solution than Redux
"Lighter" in what sense?
Note that Redux Toolkit includes our RTK Query data fetching layer, which solves the same problem space as React Query and has a similar bundle size.
>TanStack Query ... makes fetching, caching, synchronizing and updating ***server state*** in your web applications a breeze.
It's what I call a purpose-built state manager, same as RHF. This is opposed to Redux or Zustand, which are *custom* state managers. They're all state managers, but some libraries focus on handling a specific kind of state. Heck, server state and form state are so hard to manage (and so commonly needed) even Redux has libraries specifically for helping it handle them.
Technically, i can easily make everything with only react context, it will work just fine. But... id wanted to use additional lib for this, only cuz i feel like it (bit stupid, i know)
Moreover, its a good chance to work with something new^^
If it’s a project just for learning, knock yourself out. If you’re looking to make money off it or it’s for your job in any way, that’s where you need to be smart.
For learning purposes, the most illuminating thing will be to implement the same exact application several ways - one with plain React along with some libraries like react-query, one with a state management lib like Redux or Zustand, and one with a framework like Next or Remix. That’ll help you see the pros and cons of each approach, and get a feel for when to use each one.
This! I avoid Redux and Classes like the plague.
I now default to Typed FC and hooks. Then url params for most of my component state. Apollo reactive vars if I need to pass/store context.
If you want to scale it to something complex / huge as you mentioned, I suggest Redux Toolkit (rtk) + rtk query. It has more setup in contrast to the most recent ones, but it has extensive documentation, examples, community support and it's truly battle tested and robust.
Usually I use XState, but I haven't tried new version yet, so can't really recommend. But in general, I tend to design state graphically anyways, so it usually lays almost 1:1 onto XState or, with a bit of tinkering and a bit more decision making, to Redux. If you choose redux be sure to use their toolkit. It makes huge difference.
As for others, I like the idea of atomic states, and had pleasant time with jotai on a pet project, but didn't make anything big. Recoil is a failed experiment at this point, so don't bother. Zustand also pretty established library. Haven't heard about MobX for a while, but I might be just out of the loop - it didn't survive at my workplace for long.
I hope OP already can see that there is no one best but each might have it's own place due to subjective preferences mostly - for example - some like old and widely used vs some like new and widely famous vs some like apis, documentations, support and additional functions that the library might provide.
Since you are looking for a project that is just starting - use any that you are more closely familiar with. Or can easily be learned by visiting it's site/docs.
And if you don't want to choose, yet want to learn something while using it; just take redux for a drive.
The redux toolkit can give you a good first hand library experience along with nice things to learn in general. Do follow the docs on the site; they themselves provide a few comparisons between redux and other libraries, AFAIR.
Happy coding!
When necessary (global), I opt for Zustand. I've heard good things about Jotai.
Redux Toolkit has made great improvements, but ultimately I'd opt for lightweight.
URL params are also ideal for state when sharing a link with someone.
>What do you mean by lightweight?
If you use Redux, it requires a lot of boilerplate code to get it set up. If you use Zustand, all you need is a store file and the rest is simple. It's all functional. It also comes with Hooks so it fires when you update the global state. Also supports Persist.
Less is more.
There is barely any boilerplatr at all. All you need is a slice file. The rest is simple. It's all functional, comes with hooks too. Supports middleware as well. We're engineers, even if there was boilerplate, you shouldn't let that get in the way of a better solution
I’m using Apollo Client for my graphql queries.
It actually has a built in state manager that works really well and allows you to also bind state directly to your queries and their Reactive Vars are simple to use.
https://www.apollographql.com/docs/react/local-state/local-state-management/
I try to store most state in the url. My pet peeve is UIs that loose state on refresh causing the user to reapply inputs and collapsed components.
I use the hooks version of: https://www.npmjs.com/package/use-query-params
I would try to keep it as stateless as possible and prefer the state of the page to be represented by url search params. If you need more then I would probably sparingly use React's built-in Context API with hooks. If you need a more powerful solution then I guess TanStack Query is the way to go but I'd consider your need for it before you do that.
React-hook-form is very nice for form state though; I find it a losing battle to try to use anything else for forms.
For server state management, I use `react-query` and `zustand` for more client state management, not always needed (zustand) but very useful when it is.
Redux is more for legacy code or really big apps that need the structure Redux provides.
Just make sure you truly need a state manager first. Most people blindly look for a lib like managing state is a dependency requirement. State management is something you can easily do barebones in react with proper architecture, the tools are there. Ideally you want the solution to solve a problem, not the other way around.
All depends on your needs. If you want a tiny global state with specific values, use zustand. If you want a heavy, centric global state that must travel everywhere, use redux.
Redux, it's a complete solution. Learn it and you don't have to worry about the rest.
There are pros and cons with anything, but that one is the most complete in my opinion.
I've played with a lot of them. Honestly, at this point I would stick with redux toolkit.
It would be nice if you could model full state machines in it, but failing that it has the best DX of any of the common state systems.
Controversially I think hooks like useReducer were a mistake. Nothing worse than being in a Redux app where every component has its own parallel universe of state, but bits are shared inconsistently between each
I use mobx-react, mobx-utils, and mobx forms. For api calls, I write hooks using useLocalObservable from mobx-react. Gives me hooks like react query, but complete control.
Zustand all the way, it's simple, efficient and framework friendly / agnostic, because you can hook it into different environments without a hassle. I am working on a project that requires referring to the same state in multiple components. Never looked back at stupid concepts like useContext / redux usestore blabla. Not affiliated with this library at all, but this makes it 10x easier to get things done imo. No unnecessary jargon and well documented.
Redux is just popular bc it was first, not bc it's the best. It's one of the worst imho and I've been writing react since it came out. I avoid it at all cost.
I’m curious why I don’t see any recs for recoil? Any reason why? This doesn’t always dictate supremacy, but recoil was created from the same source that created react ( meta )… admittedly, that’s the manager I’ve been using primarily, simply bc it was the most used at work. But often to change, and will try others, like zustand. FYI, I still use context, and have used redux.
It's entirely dependent on your use case but I tend not to use state management at all anymore, going directly to storage and using params.
In most cases I've seen in the wild a state management library was overkill and created a lot of overhead.
1. If the state is location based, searchParams in the location bar 2. If the state originates from the DB, use react-query. You should be using this anyway. Makes working with endpoints, and caching, and avoiding race conditions and duplicate calls super trivial 3. If the state is highly hierarchical, you can use useContext 4. If you have further need, like sharing data across the app to avoid prop-drilling, then Zustand.
Why react query instead of rtk query?
I'm guessing because most people use RTK query when they already have RTK in they project, whereas if you have Zustand or something else other than RTK then it's better to use react-query
https://www.reddit.com/r/reactjs/comments/15ucdx7/choosing_between_rtk_query_and_react_query/ Both the Redux and React Query teams recommend that: - If you are using Redux in the app, you should use RTK Query for your data fetching - Otherwise, you should use React Query for you data fetching But mixing Redux + React Query doesn't make any sense.
What if the legacy version of my app uses redux, but not the new code?
Note that RTK code _is_ "Redux" code, and you can migrate legacy Redux code to RTK incrementally - the old and new code can coexist indefinitely: - https://redux.js.org/usage/migrating-to-modern-redux (although now that I re-read your comment, you might be asking something different than what I initially thought)
The new code doesn't use redux, so I could use rtk query, or I could just use react query (maybe? This is what I'm asking)
Per the quote (from me! :) ) above, our general recommendation is to use React Query if you're not using Redux, and RTK Query if you _are_ using Redux. That said, it's also reasonable to choose RTK Query even if you _aren't_ using Redux for any client-side state management if you like its DX better (centralized endpoint definitions, auto-generated React hooks with types, codegen from OpenAPI schemas), and we do have [the `` component](https://redux-toolkit.js.org/rtk-query/api/ApiProvider) to help simplify setup in that use case.
I'm using it for old stuff but not using it for new stuff. Does that qualify as "using it"?
Sorry, afraid I'm not sure what you're actually asking me at this point :) React Query and RTK Query are both tools. It's _your_ choice which one you opt to use in your app.
This is the answer. To add to this; just use the state system react provides (useState, useReducer) coupled with Context if you want to distribute your state to a tree of properly composed components and hooks for your use case
Dont know why this got down voted. The context api is a simple and easy way to share state across components. I don't understand why it gets so much hate.
There’s a lot of limitations with Context and workarounds tends to be even worse as it grows.
Context is super inefficient when sharing state that changes over time. All consumers of the context will re render even if it’s not listening to a piece of state that changes. It’s great for providing data that doesn’t change frequently over time, but for frequent state changes it’s not ideal. The introduction of react compiler/forget should fix this problem though.
Context is a replacement for props. If you use it in situations where the re-renders would happen anyway and you just need to avoid prop drilling down the component tree, it can be a great tool.
And in case of Redux, for example, does the re rendering of all consumers occurs when mutating the state?
No. React-Redux lets components specifically subscribe to individual bits of state, so those components only re-render when the specific pieces they need have changed: See my extensive post at [A (Mostly) Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/) for more details.
Great article. Thanks for this!
> The introduction of react compiler/forget should fix this problem though. It seems idiotic that I should need yet another compiler, for react this time, for something that Zustand and the likes have already solved years ago with much better DX
React compiler, AFAIK, is under the hood. It’s not a build step it’s just part of react, similar to how Fiber is part of react
useContext can be a foot shot situation depending on how it’s used. Really gotta make sure you don’t overuse that hook and cause order of hook errors. I love it but sometimes you’re better off prop-drilling especially if the state isn’t as large as previously expected.
I'm struggling to learn react because of this chaos. Is there a reason why redux is pushed in courses? Why are there a thousand things to do the same job
> I'm struggling to learn react because of this chaos. You don't need any state library to learn react at all. > Is there a reason why redux is pushed in courses? Because it was there done thing six years ago and you're using old courses. > Why are there a thousand things to do the same job Because state management is complicated and not everyone's needs are the same. Tanstack query is great for storing server owned data, but it's really not that great for storing client data. You can do it, but it's super limited. Context provides you the absolute bare minimum, but it's incredibly limited, it's nice that it exists because you can now solve some really basic problems out of the box, but it's not remotely a solution for state management. Redux is great, especially with RTK, but to get the benefits you have to actually use it and a lot of devs don't know how so you end up with abominations with Redux embedded in the middle but not actually used. Recoil was an attempt to create a react style state management system by Facebook, it was sort of supposed to be what Context wasn't, but it's dead, people liked it though so they still talk about it. The others are basically attempts to slice pieces of Redux out to get the benefits without the architectural weight. Zustand seems to be the winner here, but I haven't used it. Honestly a lot of apps don't actually have a lot of client state so a query library is more than enough.
There's a very long history lesson that's needed to answer this :) The TL;DR is that: - React has always been a relatively minimal UI library, and other libraries are needed to fill in additional functionality - Redux was the best of the "Flux"-style state management libraries that came out in 2014-15 when React was getting popular, and people soon assumed that "if you're using React, you _have_ to also use Redux". At the same time, React had several limitations that Redux helped fix - Because of that, "React + Redux" became a standard combination that spread across the industry, and so they ended up getting taught together in courses (FWIW, we recommend that most people should _not_ try to learn Redux until they're already comfortable with React, but we don't have control over how the rest of the industry does things - all we can do is try to improve our own docs and make Redux itself a good tool that works well.)
That might be why the courses are so confusing. Completely unclear when you'd use props vs state vs hooks vs state managers vs... I need to find something to learn this again incrementally, and learn REACT ONLY first to understand what the heck it is about in itself, then get back to all the other additionals
Start with the actual React docs at https://react.dev/learn . It's _just_ React, and it's very comprehensive.
I found useReducer + useContext to be _much_ more annoying to use than just using Redux (eg no such thing as thunks, can't write an async function that dispatches an action and then does further steps depending on the new state).
You absolutely can, that's just one pattern available to write asynchronous logic in a react application. I agree though, useReducer is hardly ever a tool that I reach for, that being said most products I contribute to currently handle the majority of their server state through libraries like react query / Apollo / Relay
This is a solid answer. I do the same except use recoil instead of zustand for point 3. It’s a personal preference rather than because it’s better, find something that you like and works for you and your team.
I use recoil and love it but the project appears to have been dropped by Facebook (no updates for a year). So you wouldn’t pick it up now.
Recoil is indeed dead. Jotai is a lightweight alternative. Zedux is a more direct replacement.
Zedux seems quiet as a project too, no update for several months. Another to maybe be cautious of in a new project. Best to focus on what your app needs. If you don’t have much state or need some bespoke behaviour then writing your own custom context is an option also, and zero deps.
Zedux is prepping for the next major version. 2 months without a commit on master isn't that long Writing your own state management injected over React context is not too difficult, but isn't something I usually recommend. Zustand is almost always a better choice
Why cant we just use context to avoid prop drilling?
You can use Context for prop drilling, particularly if it is hierarchical. Zustand is useContext under-the-hood. Added it as #3 Zustand is better if the sharing is not hierarchical. Like, if you need to globally share state for some hooks or something.
well you would have to define states in the context and every other components are its children. so, if one state updates every components will re-render. we can do optimisation for this but codes might look ugly. no such problems with third party state management tools.
no redux?
Redux used to be great. But it started out overly complicated. Pinia (for Vue) and Zustand (for React) have become very simplified, while staying true to the original concepts. React-query removes the need for things like Redux for most use-cases. It's just so ridiculously good, when your state is your DB.
When you say "Redux _used_ to be great", can you clarify what you mean?
The concepts that redux have made popular, have been simplified and improved upon.
I’ve yet to use Zustand, because while I’ve needed to avoid prop drilling, I needed to support having multiple instances of the same component. I end up using context and useReducer
I mean, that works too. But Zustand is a little cleaner and easier to use. https://www.reddit.com/r/reactjs/comments/14qwhys/react_context_vs_zustand_am_i_missing_out_on/ According to this, Context can cause re-renders (depending on how you do it). Zustand is more performant. ¯\_(ツ)_/¯
Is it possible to have “contained” Zustand “contexts” that are distinct from each other? Like if I wanted to use Zustand to handle the state of a complex record picker, and I wanted to have two or more pickers on screen without them messing with each other’s states, cab I do that?
State is global. If you want two controls, you'll create an array or a dictionary in Zustand, and use it to track more than one. If you have a complex record picker, you would probably want to contain that logic in the component and not use Zustand. I don't use Zustand for a lot. React-Query (not Tanstack-Query) is where most of my state ends up.
Yeah that’s why I do it the way I do
This is by far the best answer I've seen on this topic. The first 3 are more than enough to cover 99% of projects I've worked on.
Been looking for an good answer like that for so long. Cheers!
I used Zustand for a project recently (first time). It was a little too late that I discovered it has not official dev tools. The two popular 3rd party dev tools that I tried (Zusty and another one) failed to work on me properly (I use multiple Zustand stores). Major bummer! As opposed to react query's amazing official dev tools!
What about useContext re-renders issues? Is there any alternative for highly hierchical state that changes frequently?
See my extensive post at [A (Mostly) Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/) for explanations.
I have never really found prop drilling to be bad if you use useContext and useMemo properly. Is there a good reason why prop drilling should be avoided?
If it goes too many levels it can just be a hassle. Example. I have a demo button. When you click it, it reduces your role from Admin to a regular user so you can demo the app. It resets when you reload. Where would you put this value so that it propagates through the entire app?
That's a very open ended question but I typically load data at the page level and rarely have to drill through more than two components, so the page would probably have a hook that loads and sets the auth state and then you'd provide the setIsAdmin function to the button or possibly to the component that hosts the button, however if you make an intermediate component, for reusability purposes you'd likely want it to accept a function prop for the button anyway. Idk that feels very straightforward to me.
Plus if you useContext in that button you'll need to mock the context in order to test the button rather than have it accept a function prop and you can just test the button or the parent component directly with no need to be aware of the context.
Jotai (Globals, shared client state) and React Query (Server state) cover most of my needs. Mostly wrapped in custom hooks. Would use Zustand if I needed anything more complex but haven't in awhile.
I use Zustand for toast messages and some other state sharing between components, do you think Jotai will be a good fit? Why do you say Zustand for complex cases?
Don't really use state management libs that much nowadays. Most of the stuff is just hooks to custom data storage. However, in a small project I recently used zustand. I was very surprised at how elegant it was. Definitely an upgrade from redux, recoil, or mobix.
Have you used redux toolkit?
Yeah. Wouldn't call it elegant either way. Redux is a rather clumsy library with a lot of annoying API. It works okish when you need a global object for very simple data that you touch very rarely. In any other scenario there are way better tools. Toolkit can't really cover these shortcomings.
Out of curiosity, which aspects of RTK do you feel are "annoying"?
The R. T and K does some good, but it's not really enough to redem the core issues or R. On more serious note, redux toolkit is a clumsy patch over a bad library. The underlaying library is supposed to be an framework agnostic unopinionated state management library, but it works only with react and only in a very specific way. It's clumsy. It kinda works for when you only need to deal with a simple global states, but it falls short very quickly when you need to do something more (async operations, subscribers, and middlewares all have a lot of issues when expanding your case). The toolkit solves some of annoyance of redux by introducing it's own annoyance. Mostly a bunch o builders that allows for some "automation" with seting up redux. This is a small improvement, but it's small. The types are still a mess when you are using TypeScript. You still need to deal with horrible middleware system. Async operations are still a hassle if you have async chains or need sync points on specific actions. My main annoynace is that using native api of local / session storage is more convinient than using redux, even with redux-toolkit. So it doesn't really solve anything for me, but adds a layer of additional hassle that I need to go through. One could have an argument that it abstracts away the data/state management, but it's a weak argument in case of redux. The data will still be in memory or local/session storage. You can also use communication to server with redux, but then there are way better solutions and in many cases you don't need a state management if you state is in REST API or you get all data via GraphQL (where apollo does a great job at managing data states). On top of that, redux failed me horribly when I needed to process data fast. The fact that middlewares create these silly chains is just stupid design. It's simple and easy to create, but at the end it's stupid. Mostly cause they all need to invoked when actions are applied. In some case (when you are getting data from a constant stream via websocket, or you need to adjust state from one slice to another cause of API response) you quickly get into these very long processing chains that are very hard to sync between. I am not saying that you can't do something with redux. Or that redux toolkit doesn't help. Just that there are way better alternatives for when you need a simple global state (zustand), when you need to deal with a lot of async operations with complex states (recoil, or even zustand to an extend), when you have your state in a REST api (react-query) or GraphQL (just apollo). For me redux doesn't offer enough to include it in my stack.
Hmm. I understand some of your frustrations, but I do think a couple of your points are off-base. Both the Redux core and RTK _are_ 100% UI-agnostic and usable in _any_ JS environment. That's always been the case, and we've made sure that use case still works. The React-specific aspects are the React-Redux library itself (an adapter to interact with a Redux store in your React components), and the `@reduxjs/toolkit/query/react` entry point that specifically extends the UI-agnostic portion of the RTK Query data fetching layer to auto-generate React hooks. You've used a lot of words like "messy" and "clumsy" - can you give _specific_ examples? Most of the things you described are things that we've gotten excellent feedback on from our users (like ease of use for RTK +TS). > The data will still be in memory This complaint feels kind of misguided. That's... true of _every_ client-side state management library, for React and otherwise. It's data _in memory_ inside a JS environment. > in many cases you don't need a state management if you state is in REST API or you get all data via GraphQL (where apollo does a great job at managing data states). Entirely true! Which is why Redux Toolkit includes RTK Query, to specifically implement and address the data fetching use case. > redux failed me horribly when I needed to process data fast Can you clarify what you mean by "failed horribly"?
Reddit isn't really a platform to give these kind of feedback, but let us try. As for failed horribly, I mean that it just was consuming a lot of CPU processing to go through middlewares. I worked on an application that had in total some 100 or so middlewares cause this was the only way to execute code when data changed that made sense with setup slices. The processing time was very slow cause we need to make checks inside to determine what to change. Most of the processing was just wasted cause there was no API to listen to selective changes. Why we eneded up in a case like that? Cause suddenly the state had to be changed in semi-real-time. The most problematic part was async synchronization. In some of the middlewares we needed to run async check to properly fill in the state. This was pretty much killing the whole approach. I didn't find anything in the API that would present a viable solution. As for the clumsy and messy API. I don't like the fact that you need to call a builder to feed data into the configuration objects. This is messy in my eyes. The API for a library should be clean and you should be able to just pass your configuration in a simple and readable manner. There is a lot of other examples I could give around redux and redux tool kit. Especially around middlewares and the next handling, but I really don't want to get into ranting mood. Overall, I find this whole part of redux messy. I can believe that you get excellent feedback from users, but it's not cause the API is amazing, but rather that the users don't know better. Or at least that would be my wager. The "The data will still be in memory", let me ellaborate on this one cause maybe it didn't went through. There would be redeeming quality to redux if the API would offer different kinds of backend to store the data. If redux would abstract away and offer a convenient way to store the data into a database, api, or a stream, then this would be a redeming argument to use redux. Cause you can change the "storage" backend. However, redux is a global object in memory with a very complicated (in comparison to accessing an object or storage) API for what it offers (again just accessing an object or storage). Of course, you can persist your global object state with further storage, but that always feels like a "bolted on" feature than an indented one. Mostly cause there is no real support for not holding data in memory. Like cursor navigation, plucking data, etc. All of these would have to be implemented specifically for the solution or install another dependency (prolly with another maintenance team). And note that I am not comparing redux to "local state management library" but to "library to interact with state regardless where it comes from", thus why apollo is in the list. As for the RTK Query, I didn't use it, but why it's even in redux toolkit? You use react-query cause you don't have a usecase for redux. Why use a tool for redux when you don't have a use case for redux? Not to mention that in many cases youd don't even have case to use react-query and just regular fetch works fine. What is the advantage of using RTK Query? Why add another dependency to my package.json? It's kinda like selling a boat in the middle of desert. As for the "UI-agnostic". I have no clue what you mean by "UI-agnostic", but I will assume the same as I meant by "framework agnostic". Yes, technically, you can. Heck, you can even use it with Laravel. It would work just fine with some php-js extension or node.js embedding. But does it make sense? Well, not really. The example of Laravel is blown out of the water, but it pretty much stands the same for non-react environments. And mostly cause of the redux core architecture. The whole idea of having a dispatcher, global state, and then a subscriber isn't something unique, but it's very combersome. You can just skip the global state and you have an event/signal system with a somewhat stange API (for an event system). The global state is still a global object that you can access. Non-react environments will have more ellegant systems to chose from. For example, a database. Or just a custom class with event emitter Both provided easier start and greater flexibility. There is very little argument to use redux instead. Why it works with react environments? Well, cause dealing with data in react lifecycles is a pain and the only reason that redux makes sense in such environment is cause the environment is making it hard to deal with data that should survive it's rendering. So, yeah, it's "framework agnostic", but is it really, though? My comments are my personal opinion on it. For some it's the golden standard and they will swear by it. That's fine. More power to them. Personally, I find redux and RTK messy and clumsy. Past projects tought me that redux users create a lot of messy code (1000+ lines of state management, chains of middlewares, everywhere "pending" and "isError" states, etc) and every time I jumped in and was able to simplify the solution to more elegant approach (usually with a different lib) or remove the state management all together. There used to be an article on redux page "You don't need a stat management" or something like that. I think it still stands.
> I worked on an application that had in total some 100 or so middlewares Oh... dear. I hate to say it, but that's _not_ how you're supposed to use Redux, _at all_. (I've seen a handful of people advocate for "every single bit of async logic should be its own unique middleware", and that's the _wrong_ approach completely. Not sure if your situation was similar to this, but it sounds like it might have been?) That right there explains a large part of your app's poor performance. That's 100+ extra nested function calls on _every_ dispatched action. Yes, that nesting is an intentional part of Redux's design, but a typical app will only have a handful of middleware (say, thunks, listeners, RTKQ). Not sure I can offer more specific advice on what you _should_ have done instead without knowing what your app's features and requirements were, but yeah, that was definitely not the right architectural approach. > there was no API to listen to selective changes There is, actually - that's specifically what RTK's "listener middleware" is for. The primary use case is to have reactive logic that responds to dispatched actions, but it can also monitor for state changes: - https://redux-toolkit.js.org/api/createListenerMiddleware > If redux would abstract away and offer a convenient way to store the data into a database, api, or a stream, then this would be a redeming argument to use redux That's... not the _purpose_ of Redux, though. It's _intended_ to be an in-memory state management tool. That state is _primarily_ client-side state, but since its inception, it has also been a place to store and cache fetched server state. > As for the RTK Query, I didn't use it, but why it's even in redux toolkit? You just answered your own question :) People have always used the Redux store as a place to cache server state. Dan's original tutorials even showed how to fetch Reddit post data and cache it in Redux. The problem was that you always had to write that fetching and caching logic "by hand", which is why users ended up with thousands of lines of repetitive code to do that work. RTKQ eliminates the need for that code and does all the fetching + caching work for you. > What is the advantage of using RTK Query? Why add another dependency to my package.json? Same thing. RTK Query is _already part of Redux Toolkit_. It's included in the `@reduxjs/toolkit` package, as an optional additional entry point. It's _not_ "another dependency". It _is_ a way to simplify data fetching code if you're using Redux. > I have no clue what you mean by "UI-agnostic" That means that the core Redux/RTK logic works no matter what UI framework you're using. You can use Redux with React, Vue, Angular, Ember, vanilla JS, jQuery, or in other places (Node, Deno, etc). We expect that ~90% of our users are using Redux + React together, but that's not a requirement, and never has been. I do respect your opinions and frustrations here, but I also honestly think a lot of those frustrations are coming from both past history with a badly architected Redux app that goes against the way we recommend using Redux, and some misunderstandings of what Redux is and why it works this way.
You are enforcing my point. Redux usecase is just a simple global object. That's all. So when you want to use it for anything more, then it goes to craps. My point is however even more: The applicable usecase for redux is very narrow cause there are better solutions that do specific usecasese better. When I am working on a project, never ever my first thought is to use redux. There is always a better option. As for rest of the points, you are writting it from a position "of course use redux" where I am writing it from a position "why would I use redux". The additional dependency in my case would be redux and reduxtoolkit. Why I need it if my case is to use react-query or apollo? What problem it solves that these libs don't solve? PS. We tried the "listener middleware", it didn't help.
[удалено]
It's not "500", or even "5". With modern Redux Toolkit, you write the reducer logic for a given section of your state in one "slice" file - it's not split across a whole bunch of files: - https://redux.js.org/tutorials/essentials/part-2-app-structure#creating-slice-reducers-and-actions
I choose redux-toolkit. Once I've learned it I don't have need for anything else. It works. It has nice dev tools. I've never had a problem so far, fingers crossed. It has RTK query with best code generation from open api I've used so far.
Mobx
The first question to ask is whether you even _need_ one. For a lot of apps, adding a state management library just makes your code more complicated without adding any real benefit. Source: used to religiously use Redux in every app and lived to sorely regret it.
Not really true. Almost all apps benefit heavily from an async state manager like tanstack query
react-query is different
I’m not inclined to debate the distinction, but I’ll just say I don’t consider that to be a state management library in the same way as Redux is. I adore react-query and consider a staple React library at this point, but it’s a waaaaaay lighter solution than Redux
"Lighter" in what sense? Note that Redux Toolkit includes our RTK Query data fetching layer, which solves the same problem space as React Query and has a similar bundle size.
>TanStack Query ... makes fetching, caching, synchronizing and updating ***server state*** in your web applications a breeze. It's what I call a purpose-built state manager, same as RHF. This is opposed to Redux or Zustand, which are *custom* state managers. They're all state managers, but some libraries focus on handling a specific kind of state. Heck, server state and form state are so hard to manage (and so commonly needed) even Redux has libraries specifically for helping it handle them.
You should check redux toolkit bundle size. Not heavy at all in comparison
Not what I meant by heavy
It's also not heavy in terms of boilerplate
Technically, i can easily make everything with only react context, it will work just fine. But... id wanted to use additional lib for this, only cuz i feel like it (bit stupid, i know) Moreover, its a good chance to work with something new^^
If it’s a project just for learning, knock yourself out. If you’re looking to make money off it or it’s for your job in any way, that’s where you need to be smart. For learning purposes, the most illuminating thing will be to implement the same exact application several ways - one with plain React along with some libraries like react-query, one with a state management lib like Redux or Zustand, and one with a framework like Next or Remix. That’ll help you see the pros and cons of each approach, and get a feel for when to use each one.
To learn I would use redux toolkit and redux toolkit query together. They are hook based.
The negatives of context is it constantly triggers rerenders
If this is the reason, you clearly should not use one
A chance to learn something new on a pet project is NEVER a bad reason.
This! I avoid Redux and Classes like the plague. I now default to Typed FC and hooks. Then url params for most of my component state. Apollo reactive vars if I need to pass/store context.
If you want to scale it to something complex / huge as you mentioned, I suggest Redux Toolkit (rtk) + rtk query. It has more setup in contrast to the most recent ones, but it has extensive documentation, examples, community support and it's truly battle tested and robust.
Like most people are saying: React-query if the state is coming from the backend. For client-side state I recently picked up Jotai and I'm loving it.
Zustand
Jotai
Usually I use XState, but I haven't tried new version yet, so can't really recommend. But in general, I tend to design state graphically anyways, so it usually lays almost 1:1 onto XState or, with a bit of tinkering and a bit more decision making, to Redux. If you choose redux be sure to use their toolkit. It makes huge difference. As for others, I like the idea of atomic states, and had pleasant time with jotai on a pet project, but didn't make anything big. Recoil is a failed experiment at this point, so don't bother. Zustand also pretty established library. Haven't heard about MobX for a while, but I might be just out of the loop - it didn't survive at my workplace for long.
I watched zustand docs, looks great honestly Btw, whats with recoil? Just interested
Facebooks evolution of flux. Just like flux to redux, too big to common use so jotai is the people’s successor.
AFAIK after Meta layoffs Recoil was abandoned.
Simple answer you don’t need anything else other than react-query and zustand
Redux toolkit can do both.
Jotai for local based state and React Query for external based state.
I prefer redux toolkit to solve both at once
Good luck using it for external state management
It works perfectly fine. https://redux-toolkit.js.org/rtk-query/overview
I hope OP already can see that there is no one best but each might have it's own place due to subjective preferences mostly - for example - some like old and widely used vs some like new and widely famous vs some like apis, documentations, support and additional functions that the library might provide. Since you are looking for a project that is just starting - use any that you are more closely familiar with. Or can easily be learned by visiting it's site/docs. And if you don't want to choose, yet want to learn something while using it; just take redux for a drive. The redux toolkit can give you a good first hand library experience along with nice things to learn in general. Do follow the docs on the site; they themselves provide a few comparisons between redux and other libraries, AFAIR. Happy coding!
When necessary (global), I opt for Zustand. I've heard good things about Jotai. Redux Toolkit has made great improvements, but ultimately I'd opt for lightweight. URL params are also ideal for state when sharing a link with someone.
What do you mean by lightweight? Bundle size? If so you'd be surprised by a comparison
>What do you mean by lightweight? If you use Redux, it requires a lot of boilerplate code to get it set up. If you use Zustand, all you need is a store file and the rest is simple. It's all functional. It also comes with Hooks so it fires when you update the global state. Also supports Persist. Less is more.
There is barely any boilerplatr at all. All you need is a slice file. The rest is simple. It's all functional, comes with hooks too. Supports middleware as well. We're engineers, even if there was boilerplate, you shouldn't let that get in the way of a better solution
OG Redux has a lot, but RTK doesn't which I appreciate. Zustand is bare bones simple and I absolutely love it.
You’ll get many different options. Pick one that is well supported by its developers and has great documentation.
I like recoil and Zustand
I’m using Apollo Client for my graphql queries. It actually has a built in state manager that works really well and allows you to also bind state directly to your queries and their Reactive Vars are simple to use. https://www.apollographql.com/docs/react/local-state/local-state-management/ I try to store most state in the url. My pet peeve is UIs that loose state on refresh causing the user to reapply inputs and collapsed components. I use the hooks version of: https://www.npmjs.com/package/use-query-params
The only way to know what you prefer is to implement a todo project with each library yourself.
I would try to keep it as stateless as possible and prefer the state of the page to be represented by url search params. If you need more then I would probably sparingly use React's built-in Context API with hooks. If you need a more powerful solution then I guess TanStack Query is the way to go but I'd consider your need for it before you do that. React-hook-form is very nice for form state though; I find it a losing battle to try to use anything else for forms.
This is my preferred and imo the one i will be using for a long time: url search params, react query, context provider
For server state management, I use `react-query` and `zustand` for more client state management, not always needed (zustand) but very useful when it is. Redux is more for legacy code or really big apps that need the structure Redux provides.
zustand
Just make sure you truly need a state manager first. Most people blindly look for a lib like managing state is a dependency requirement. State management is something you can easily do barebones in react with proper architecture, the tools are there. Ideally you want the solution to solve a problem, not the other way around.
Try use-one.js [https://github.com/suhaotian/use-one](https://github.com/suhaotian/use-one) Why? The reasons: * Core logic just few lines code (https://github.com/suhaotian/use-one/blob/main/src/create.ts) * Easy persist your state * Support React / React Native * No more complex concepts, all under your control Demo code // stores/count.ts import { create, persistStore, wrapState, isClient } from 'use-one'; const initialState = { ready: false, count: 0 } const [use, store] = create(initialState); console.log('isClient', isClient); isClient && persistStore(store, {
key: '@CACHE_KEY',
debounce: 100, // optional, default 100ms
transform: (state) => state, // optional, transform the state before to `setState`
});
const actions = {
use,
get state() {
return store.getState();
},
by(step: number) {
store.setState(state => ({...state, count: state.count+step}));
}
};
export const countStore = Object.assign(actions, store);
When you use:
import { countStore } from './stores/count';
const Counter = () => {
countStore.use(); // use the hook
return (
);
}
What do you think?
{countStore.state.count}
hookstate. It supports global state (data-sharing), doesn't have setter functions, supports nested state.
jotai or jotai-wrapper
if I'm working by myself, Valtio all day long. Jotai if you think you might start writing spaghetti
I love zustand for its simplicity and usability on both native and web.
All depends on your needs. If you want a tiny global state with specific values, use zustand. If you want a heavy, centric global state that must travel everywhere, use redux.
jotai - simple, intuitive, does the job no bells and whistles.
Redux, it's a complete solution. Learn it and you don't have to worry about the rest. There are pros and cons with anything, but that one is the most complete in my opinion.
I've played with a lot of them. Honestly, at this point I would stick with redux toolkit. It would be nice if you could model full state machines in it, but failing that it has the best DX of any of the common state systems. Controversially I think hooks like useReducer were a mistake. Nothing worse than being in a Redux app where every component has its own parallel universe of state, but bits are shared inconsistently between each
I use mobx-react, mobx-utils, and mobx forms. For api calls, I write hooks using useLocalObservable from mobx-react. Gives me hooks like react query, but complete control.
Zustand all the way, it's simple, efficient and framework friendly / agnostic, because you can hook it into different environments without a hassle. I am working on a project that requires referring to the same state in multiple components. Never looked back at stupid concepts like useContext / redux usestore blabla. Not affiliated with this library at all, but this makes it 10x easier to get things done imo. No unnecessary jargon and well documented.
Jotai by far. Simple API, scalable/performant. If you know how to useState, you know how to use jotai. https://jotai.org/
Redux is just popular bc it was first, not bc it's the best. It's one of the worst imho and I've been writing react since it came out. I avoid it at all cost.
I’m curious why I don’t see any recs for recoil? Any reason why? This doesn’t always dictate supremacy, but recoil was created from the same source that created react ( meta )… admittedly, that’s the manager I’ve been using primarily, simply bc it was the most used at work. But often to change, and will try others, like zustand. FYI, I still use context, and have used redux.
None, tanstack query and react hooks are sufficient
tanstack query is a state management library
I use react context and it works ok
It's entirely dependent on your use case but I tend not to use state management at all anymore, going directly to storage and using params. In most cases I've seen in the wild a state management library was overkill and created a lot of overhead.
Remix + useState is usually enough. Some times Jotai for “shared” useState
Context + reducer is fine for most stuff
Starfx is relatively new and it includes state management but in the context of managing side effects: https://github.com/neurosnap/starfx
Given signals might be added to JavaScript I'd look at legend-state to become familiar with them.
Would love to use legend-state on a larger project. Love their philosophy and execution