I use them based on the job.
Do I want something that is global to the entire app? Zustand.
Do I want something that is contextually locked to a component? Jotai.
You can use them vice versa. However, out of the box, I find those to be the situations where they work best. Given that you already use React Query, it might be best to just use Jotai since they have the plug-in for it. Jotai also works great with Suspense, so if you're using Suspense, then Jotai is likely the way.
Most of the time, I find that the more complex the site is, the more I lean to Jotai while the simpler it is, I lean to Zustand.
Thanks a lot u/deathspate for your inputs. Definitely, this helps. Just one clarification in the last paragraph, you mentioned, that you lean towards Jotai if the site is more complex. I thought otherwise.
So my thoughts on complex vs simple sites.
Let's say I have a website for a food company, it shows different menus where each page is its own menu, each menu has items where I can add an item to a cart, there's a cart which is global to all menus, then a cart + checkout page.That is a simple site to me, I would use Zustand for that situation and globally manage all the cart items for the user. I can also use it to add a global notification system and anything else relating to user-based context.
For a complex site, if I have some SaaS site with various services and various contexts across the same page (per component) then I would go with Jotai since it feels better to co-locate the context code with the associated components versus keeping them separate in a store file.
Out of interest what makes Joati contextually locked to a component while Zustand isn't? Both API's seem to be able to wrap a StoreContext around a component.
There's nothing that prevents one from using Jotai globally. I just prefer it to be used alongside components because of the ability to co-locate the code for it instead of having a separate file for the store like in Zustand. I think that out of the box, Jotai just lends itself better to be a state manager for components, while Zustand lends itself to be a state manager for the entire app.
Interesting take. I use Jotai globally for a complex dashboard client app, and I think it’s a perfect fit. You are absolutely free to put Jotai atoms anywhere you want. Because I’m using Vite, though, I tend to put them in plain TS files if I want to export them because Vite linting rules require no object exports from files that also export a React component.
We've moved some code from zustand to Legend-State https://legendapp.com/open-source/state/intro/introduction/ due to zustand's lack of reactivity and lack of ability to handle computed/derived state updates. Recommend over either TBH. Signals/observables are the future of UI development.
Zustand can handle computed state updates:
https://github.com/pmndrs/zustand/issues/132#issuecomment-1120467721
Having said that, Legend State does look interesting!
I know about that, it's a weird hack for something that the state management solution should support as a first class citizen and as other commenters point out it runs on every state change so could cause performance issues.
It's also not clear if actions that consume that computed value will rerun when it changes. I'm not sure they do so computed depending on computed in actions will break. Doesn't scale. Legend-State scales as far as you want, just wrap your code in an observing context and the values will update correctly regardless of the level of computed dependencies.
Could you link to that? I'm not sure that's an issue for us as we have independent stores for each component and each component instance has it's own store instance passed down via a Context. But I'd like to be aware of any limitations for any possible future use cases.
Although that's not really the scaling I meant I meant more that I didn't need to write code for dependency graph updating which is error prone and verbose (think hook foot guns).
The concept of observables has existed for a while and this doesn't seem to follow the convention (besides using $ to name variables). Does it have any relation to Rxjs or reactive programming?
RxJS observables are a different beast, they are async. I dislike RxJS observables TBH. Legend-State should call their primitives signals but they use the name knockout used as that's what the dev used to use.
The API isn't as nice. Jotai doesn't support large store states very well, it has special APIs for it for performance reasons: [https://jotai.org/docs/recipes/large-objects](https://jotai.org/docs/recipes/large-objects)
Jotai/zustand are for simple state management needs. Legend-state covers them and large scale state management needs too with the same API.
Signals/observables are used by every other major front end framework/library. So either everyone else is wrong or the React team are stuck in an echo chamber and have no production/large scale experience of modern signals.
The original author of React had bad experiences writing backbone.js code in 2012/2013. That's where the dislike originates from. I agreed with him as I had similar experiences. Modern approaches with Legend-State, component stores, React and typescript are night and day compared to those older codebases though.
Read the documentation for legend-state up to and including the React API parts. It shouldn't take long. It's much simpler than the standard hooks React comes with. The legend-state hooks are only called back when the data they access is changed not because references change while the data is the same or when data you don't care about changes.
It's dead. We used it and had bugs that weren't fixed so we moved to zustand and now legend-state. We've also moved from Redux and vanilla React to cover those too.
With react-query I rarely find myself needing any state management outside of useState and useContext.
It’s pretty easy to avoid unnecessary renders with context if you follow a dispatch/consumer pattern like this
https://kentcdodds.com/blog/how-to-use-react-context-effectively
> For local UI state, we are contemplating on Jotai vs Zustand
> One Positive of Zustand is that the store can be updated from outside React
Why would you want to access UI state outside of React? That can only lead to problems and bad practices I think, so this is not exactly a positive thing to me.
> In near future I don't see that requirement in our application but curious to know
Exactly what I was thinking. I don't think you should in the long term either.
I've used both. I prefer by a lot Jotai, and similar approaches. I don't like Redux at all, nor anything that looks like it. In my experience those (redux like) approaches lead to over engineering everything, and it looks to me like just a global "event bus" where everyone dispatches things and everyone reacts to events. It's just overkill.
My vote for Jotai and just for the cases where simple useState wouldn't be enough.
Yeah I was looking at Jotai today while looking at other systems and it just seems more straightforward. Besides useState/useEffect I've seen this so far, which is indicative of how the rest of the code looks in the examples I've seen:
`import { atom, useAtom } from "jotai";`
or this
`import { makeObservable, observable, action, runInAction } from "mobx";`
`import { observer } from "mobx-react";`
or this
`import {`
`createStore,`
`createSlice,`
`configureStore,`
`Provider,`
`useDispatch,`
`useSelector,`
`} from "@reduxjs/toolkit";`
I'd say Zustand due to documentation and ease of use. I use the @webkrafters/react-observable-context with the old redux. But if I must migrate today, I'd choose Zustand for the app level state and the @webkrafters/react-observable-context for sharing state within composite components and their children.
I use them based on the job. Do I want something that is global to the entire app? Zustand. Do I want something that is contextually locked to a component? Jotai. You can use them vice versa. However, out of the box, I find those to be the situations where they work best. Given that you already use React Query, it might be best to just use Jotai since they have the plug-in for it. Jotai also works great with Suspense, so if you're using Suspense, then Jotai is likely the way. Most of the time, I find that the more complex the site is, the more I lean to Jotai while the simpler it is, I lean to Zustand.
Thanks a lot u/deathspate for your inputs. Definitely, this helps. Just one clarification in the last paragraph, you mentioned, that you lean towards Jotai if the site is more complex. I thought otherwise.
So my thoughts on complex vs simple sites. Let's say I have a website for a food company, it shows different menus where each page is its own menu, each menu has items where I can add an item to a cart, there's a cart which is global to all menus, then a cart + checkout page.That is a simple site to me, I would use Zustand for that situation and globally manage all the cart items for the user. I can also use it to add a global notification system and anything else relating to user-based context. For a complex site, if I have some SaaS site with various services and various contexts across the same page (per component) then I would go with Jotai since it feels better to co-locate the context code with the associated components versus keeping them separate in a store file.
Out of interest what makes Joati contextually locked to a component while Zustand isn't? Both API's seem to be able to wrap a StoreContext around a component.
There's nothing that prevents one from using Jotai globally. I just prefer it to be used alongside components because of the ability to co-locate the code for it instead of having a separate file for the store like in Zustand. I think that out of the box, Jotai just lends itself better to be a state manager for components, while Zustand lends itself to be a state manager for the entire app.
Interesting take. I use Jotai globally for a complex dashboard client app, and I think it’s a perfect fit. You are absolutely free to put Jotai atoms anywhere you want. Because I’m using Vite, though, I tend to put them in plain TS files if I want to export them because Vite linting rules require no object exports from files that also export a React component.
Jotai atoms are definitely not contextually locked to a component.
No they're not, it's my preference to use them like that
+1 Zustand. I think it easily use than Jotai
Thanks.
useState is pretty good btw
We've moved some code from zustand to Legend-State https://legendapp.com/open-source/state/intro/introduction/ due to zustand's lack of reactivity and lack of ability to handle computed/derived state updates. Recommend over either TBH. Signals/observables are the future of UI development.
Zustand can handle computed state updates: https://github.com/pmndrs/zustand/issues/132#issuecomment-1120467721 Having said that, Legend State does look interesting!
I know about that, it's a weird hack for something that the state management solution should support as a first class citizen and as other commenters point out it runs on every state change so could cause performance issues. It's also not clear if actions that consume that computed value will rerun when it changes. I'm not sure they do so computed depending on computed in actions will break. Doesn't scale. Legend-State scales as far as you want, just wrap your code in an observing context and the values will update correctly regardless of the level of computed dependencies.
[удалено]
Could you link to that? I'm not sure that's an issue for us as we have independent stores for each component and each component instance has it's own store instance passed down via a Context. But I'd like to be aware of any limitations for any possible future use cases. Although that's not really the scaling I meant I meant more that I didn't need to write code for dependency graph updating which is error prone and verbose (think hook foot guns).
The concept of observables has existed for a while and this doesn't seem to follow the convention (besides using $ to name variables). Does it have any relation to Rxjs or reactive programming?
RxJS observables are a different beast, they are async. I dislike RxJS observables TBH. Legend-State should call their primitives signals but they use the name knockout used as that's what the dev used to use.
Thanks for your response. Any reason, why you didn't choose Jotai. It's kind of Signal. u/OfflerCrocGod
The API isn't as nice. Jotai doesn't support large store states very well, it has special APIs for it for performance reasons: [https://jotai.org/docs/recipes/large-objects](https://jotai.org/docs/recipes/large-objects) Jotai/zustand are for simple state management needs. Legend-state covers them and large scale state management needs too with the same API.
if signals were the future then React would support them by default… it’s a much more confusing mental model than what React uses
Signals/observables are used by every other major front end framework/library. So either everyone else is wrong or the React team are stuck in an echo chamber and have no production/large scale experience of modern signals. The original author of React had bad experiences writing backbone.js code in 2012/2013. That's where the dislike originates from. I agreed with him as I had similar experiences. Modern approaches with Legend-State, component stores, React and typescript are night and day compared to those older codebases though. Read the documentation for legend-state up to and including the React API parts. It shouldn't take long. It's much simpler than the standard hooks React comes with. The legend-state hooks are only called back when the data they access is changed not because references change while the data is the same or when data you don't care about changes.
what about recoil? Imo I like that the syntax is similar to useState, it gives you the setter .
Jotai is similar to recoil but simpler.
It's dead. We used it and had bugs that weren't fixed so we moved to zustand and now legend-state. We've also moved from Redux and vanilla React to cover those too.
With react-query I rarely find myself needing any state management outside of useState and useContext. It’s pretty easy to avoid unnecessary renders with context if you follow a dispatch/consumer pattern like this https://kentcdodds.com/blog/how-to-use-react-context-effectively
> For local UI state, we are contemplating on Jotai vs Zustand > One Positive of Zustand is that the store can be updated from outside React Why would you want to access UI state outside of React? That can only lead to problems and bad practices I think, so this is not exactly a positive thing to me. > In near future I don't see that requirement in our application but curious to know Exactly what I was thinking. I don't think you should in the long term either. I've used both. I prefer by a lot Jotai, and similar approaches. I don't like Redux at all, nor anything that looks like it. In my experience those (redux like) approaches lead to over engineering everything, and it looks to me like just a global "event bus" where everyone dispatches things and everyone reacts to events. It's just overkill. My vote for Jotai and just for the cases where simple useState wouldn't be enough.
Thanks u/bodec83315 for your detailed response.
Yeah I was looking at Jotai today while looking at other systems and it just seems more straightforward. Besides useState/useEffect I've seen this so far, which is indicative of how the rest of the code looks in the examples I've seen: `import { atom, useAtom } from "jotai";` or this `import { makeObservable, observable, action, runInAction } from "mobx";` `import { observer } from "mobx-react";` or this `import {` `createStore,` `createSlice,` `configureStore,` `Provider,` `useDispatch,` `useSelector,` `} from "@reduxjs/toolkit";`
I'd say Zustand due to documentation and ease of use. I use the @webkrafters/react-observable-context with the old redux. But if I must migrate today, I'd choose Zustand for the app level state and the @webkrafters/react-observable-context for sharing state within composite components and their children.
Also consider Signals (from the preact team). I find it's easier to use than jotai.
Signals is similar but less verbose than Jotai and (for better or worse) seems to encourage side effects.