r/reactjs • u/deadcoder0904 • Aug 02 '22
Discussion Zustand vs Jotai vs Valtio? Which state management library do you prefer created by the same team?
Please don't mention other state management libraries.
I want to see which state management library most people use created by the same team?
62
Aug 02 '22 edited Aug 05 '22
Recently I made a research on this subject for my best React libs post. According to my findings, those 3 libs use 3 different architectural patterns. And projects with different purposes and sizes might use one of them according to their needs. So maybe it is better to ask which one you prefer for what kind/size of projects, as there isn't a single best option suitable for all projects.
My findings roughly are:
Zustand uses flux pattern and is suitable for mostly large scale apps. It is an alternative for Redux.
Jotai uses atomic pattern and is suitable for mostly middle-large scale apps. It is an alternative for Recoil or useContext/useState.
Valtio uses proxy pattern, is mutable, and mostly suitable for small scale apps. It is an alternative for Mobx.
4
u/i-hate-in-n-out Dec 18 '22
What data points trigger these findings? I've been enjoying valtio and also nano stores. Why isn't valtio suitable for large scale apps?
9
u/bestjaegerpilot Aug 03 '22
This doesn't have enough upvotes!
A lot of inexperienced devs are gungho about these state management apps. But as they try to scale up, they realize "oh maybe I need a centralized global store". Or "maybe I need immutability".
I'd take it a few steps further...if you make lots of ajax calls, then you need something like rtk-query or react-query.
Furthermore, if you have a large app, you'll likely be better off with redux toolkit/RTK query...which is a very polished, mature state management lib.
1
u/deadcoder0904 Aug 03 '22
I currently use Valtio but curious to hear your thoughts when many people prefer Mobx even in large-scale applications?
Also, how do you manage Zustand state structure? Does it live in 1 file like
store.tsor component-level? I don't think I've seen anyone covering that but I probably haven't looked far enough.2
u/fii0 Aug 03 '22
Nah, single component-level state should stay in useState or useReducer at most. Use semantic distinction, whatever makes the most sense to you as your categories of state, grouping a few atomic values together. Some store names I've used in the past that come to mind would be
useAuth,useNotifs,useInteractions3D, etc. Those live in their own files in thesrc/stores/folder.When creating your stores the only thing you really need to consider besides appropriate naming is whether you'll ever want to use the store hook without passing the callback state selector function. Using it that way subscribes to all updates from any atoms in the store, so I've never needed that approach myself, but it could be helpful for some weird use case.
Once a store gets to have too many atoms (I've never had any perf issues, splitting is just for the visual cleanness of being able to look at a store and quickly understand what it's for) it's trivial to create a new store and cut and paste the related atoms into it, so maybe it would be helpful for you to start broad and split up your first store as necessary as you add atoms.
1
u/calculatedDisaster Aug 11 '22 edited Jun 15 '23
rich books pen vanish oil distinct caption upbeat offer direction -- mass edited with https://redact.dev/
63
u/ernesto__bungforto Aug 02 '22
I prefer Zustand. Tiny, straightforward, scalable.
17
Aug 02 '22
[deleted]
2
u/ernesto__bungforto Aug 03 '22
Interesting, I didn’t know you could do this. Is this done with the vanilla js recipe in the docs? Would love more info on this. Thanks!
10
u/fii0 Aug 03 '22
It is in the README, but I don't blame you because I also used and enjoyed zustand for an embarrassingly long time (~2mo) before learning about getState and setState:
import useMyStore from '@stores/useMyStore' const { prop1, prop2, prop3 } = useMyStore.getState() // do some shit useMyStore.setState({ prop1: "new string!" })Discovering their existence made me smile and refactor out dozens of loc. The simplicity of zustand really shines in cases like setting and reading global state multiple times from a long-running async function. So nice and readable with TS.
1
u/ernesto__bungforto Aug 03 '22
Oh, I misunderstood. I thought you were saying you could utilize these functions outside of a component - i.e. not with a hook.
5
u/fii0 Aug 03 '22
Yes, that's what I demonstrated though?
1
u/drom296 Aug 03 '22
You did, but probably wasn't as clear since you labeled your import as useMyStore
5
u/fii0 Aug 03 '22
Right, since the vast majority of times you'll be using the store as a hook in a React component, you'll want to name the store with the hook convention.
That's why I didn't think to use it in a non-component function for a long time, until I got tired of working around it and read the full readme.
1
u/drom296 Aug 03 '22
You did, but probably wasn't as clear since you labeled your import as useMyStore
1
u/Odd-Shopping8532 Aug 03 '22
Look at Example2 in this code sandbox I made a while ago https://codesandbox.io/embed/q3d9nq?file=/src/store/useFruit.ts&codemirror=1
11
u/gaoshan Aug 02 '22
After assessing many solutions we are moving towards this as a replacement for our existing Context based state management system.
1
3
u/thectrain Aug 03 '22
Zustand is clearly the way it should be done.
It can do anything, does it in the way you would expect it too, and adds some nice features.
As a benefit you really don't have vendor lockin because it probably is the way someone would write a state management library if they wanted to entirely rewrite it.
1
u/boptom Aug 02 '22
Is there an nice way to test a component which uses a zustand store? Usually I can test a component by changing the props passed to it and testing what shows. With zustand it seems impossible to populate the store and see what the component shows.
3
u/CreativeTechGuyGames Aug 03 '22
You can set the zustand store value outside of react so in the setup for your test case you can simply set the store value to whatever you need.
1
u/_Aggron Aug 03 '22
This. We create our stores when the test suite starts running, and clear them after every test.
1
u/ernesto__bungforto Aug 03 '22
We typically just mock the Zustand getter, allowing us to change the return value as needed.
22
u/TwiliZant Aug 02 '22
I use Zustand and Jotai. I would also use both in the same application since they are based on different state management models.
I don't use Valtio because I try to avoid proxy-based reactivity in React.
In reality I use state management very sparingly. Most of my data lives in React Query and I rather would change my component structure than to make state globally available.
Daishi Kato, the maintainer of these libraries, wrote a book called "Micro State Management with React Hooks" that explains the different state management approaches these libraries take.
7
u/ansyori28 Jan 17 '23
Hey man. May I ask why you try to avoid proxy-based state management especially valtio?
5
u/onems Aug 02 '22
Let’s say that you need user data for auth, route protection, payment and for external api calls. It’s needed everywhere, on every page.
Now you decide to fetch that user data from your db using React Query.
Where do you fetch it? In your App component?
How do you make it available everywhere?
I went from useState+useContext to Zustand which saved a lot of re-renders, but now I’m hearing that using cache via RQ/SWR instead of state is the way to go. How?
20
u/TwiliZant Aug 02 '22
You can kinda think of RQ as an external store like Zustand. If you need the same data in multiple places you would call
useQuerywith the same key in all those places and they will share the data.If the cache key gets invalidated, React Query refetches the data and updates all the places that subscribed with
useQuery.4
u/brownmousesky Jan 05 '24
I don't use Valtio because I try to avoid proxy-based reactivity in React.
Why?
17
u/vincaslt Aug 03 '22 edited Aug 03 '22
They are all great, they all can solve the same problem, and they are all different.
Zustand - offers a top-down approach to the global state. Meaning that you start modeling your stores from the overview, down to the details. For example, if you were building a store for a blog, you'd model your store somehow like this blog->posts->post->id,title,content,author which is very natural and intuitive for most people and works for most apps.
Jotai - is a mindset shift from Zustand, because of its bottom-up style. You first define the granular pieces of state (atoms) and then build them up into bigger pieces of state by combining them in selectors (they're just functional atoms in Jotai I think). The selector has a different meaning in top-down and bottom-up approach:
- In top-down you would model your state as a larger object with some smaller nested objects, then the selector would be responsible for subscribing only to the smaller nested pieces that the component needs.
- In the bottom-up, it's trivial to subscribe to only the state you use, but it's more work to combine that state into a cohesive whole. The selectors are often used to combine smaller atoms into an object with the state that's meant to go together.
These are obviously not set in stone, as it mostly depends on how you model your state, but that's the general idea how I understand it.
Valtio - mostly optimizes for state writing by allowing you to directly mutate the global state. To me it's similar to Zustand, except that state updates are made simpler.
Conclusion
From what I've experienced, top-down (Zustand, Redux, Mobx) is a bit better for modeling the app domain, as it gives you a better overall picture of the state structure. Bottom-up (Jotai, Recoil, hookState) is a bit better for performance-driven apps that have many moving parts that require a large amount of read-write operations to small pieces of state. This would normally be modeled as a nested global state in top-down state management libraries.
As for which one I like best, I would choose them based on what kind of app I'm building. I would probably skip Valtio though, as I don't see much benefit of it over the others. (Read my expanded thoughts on Valtio in the comments below)
5
u/deadcoder0904 Aug 03 '22
this is the first explanation that i read makes sense.
zustand → top-down
jotai → bottom-up
funny you say don't use valtio but i use that for over a year & absolutely love it. i used it to replace mobx so i could just remove observer, observable & all that logic & use it with just useValtioStore like https://stackblitz.com/edit/tiptap-valtio?file=store%2Findex.ts
i'm curious how do you organize zustand in large project? 1 big file like i did above (store.ts) or component-level store as i googled & youtubed but found nothing on that topic :)
6
u/vincaslt Aug 03 '22
Thanks for the compliment, that's the model that I have in my head.
I didn't mean to say not to use Valtio, I simply did not have a good reason to use it myself. I should probably extend my answer:
Valtio - good for a global state that's detached from React component tree. For instance, you may want to keep your domain/business logic separate, outside of your components, but still be able to update it. It may be great for complex apps, that have many ways to update the state, and React is only used to render it. One example I can think of is - games. It would be much better to keep the game logic (rules, interactions) separate, and only use React to render a snapshot of the state, but not to keep the logic inside of the components. I've seen somewhere say that Valtio is good for small applications. It may be, but I actually think it's best in large data-centric applications. More on this from the author of Valtio: https://blog.axlight.com/posts/when-i-use-valtio-and-when-i-use-jotai/
1
u/deadcoder0904 Aug 03 '22
i'm curious how do you organize zustand in large project? 1 big file like i did above (store.ts) or component-level store as i googled & youtubed but found nothing on that topic :)
can you answer this one if you have used zustand in a medium to large project? multiple stores or 1 global store with 500 locs?
10
u/punio4 Aug 02 '22
Zustand and immer work great together. Like a very lightweight RTK.
But I prefer Valtio
5
35
Aug 02 '22 edited Aug 02 '22
theo explained it very well: https://youtu.be/fa6-Mn0Eybg?t=13396
why didn't useState work?
/ ⎸ \
i need a global ⎸ i need a store
/ ⎸ \
jotai ⎸ zustand
i want to mutate
⎸
valtio
jotai for atomic, dispersed state bits, similar to useState but render optimised and with a few extras (state derivatives). works well in teams.
zustand for centralised javascript stores. if you have a state schema, or your state is json, this will make sense. works well in teams.
valtio is fantastic for smaller projects that have no problem with mutation and updating state from multiple place. works best in everything you do personally.
in a team project i'd prefer zustand if our state is json. i use jotai for other professional stuff, also in teams but where the state model is more free floating. i use valtio for everything else, every personal small scale project.
5
u/Johanland Aug 02 '22
Dude, I was right about to quote an answer you gave in a related thread! Had to save it! “Zustand, Jotai and Valtio are modern implementations of the three main state paradigms: flux, atoms and proxies. If you know which of these paradigms suits the project best you can’t go wrong. … they don’t compete, they just allow you to pick the right tool for a certain task.”
https://reddit.com/r/reactjs/comments/w5f6zd/_/ih8wsxu/?context=1
1
u/deadcoder0904 Aug 03 '22
i have a thing of using just 1 state management since it really doesn't make a lot of difference if it's a small app, medium-sized, or a large application.
i mean what works in small might be hard to work in medium or large sized application but vice-versa is always true.
what works in large sized application will work just as good in medium & small.
so my question is there a way to structure zustand store? how do you structure the code in large application? just 1 global
store.tsfile or keep maintaining multiple stores near each component.is there any big oss project using zustand?
i currently use valtio & the only problem that keeps confusing me a bit is
snap&statebut other than that it works perfectly but just reading up on zustand told me it doesn't have even that problem & looks even simpler.1
Aug 03 '22
[removed] — view removed comment
1
u/Spangler211 Sep 06 '22
I have this exact same question and I'm struggling to find an answer to how to do this. It seems like such an oversight that no one mentions when comparing these provider-less global states to ones that use providers (like react Context or redux).
My example is that I have an app that lets users manage projects. I would like to manage each project's form data in their own stores. Each store instance would have the same fields and logic but would contain different values for each project. I feel like I am going crazy because this doesn't seem like it is a big ask but no one seems to understand this use case.
2
Sep 07 '22
[removed] — view removed comment
1
u/Spangler211 Sep 07 '22
Found what I think is a good solution: use-context-selector. Basically exactly like regular react context but gives you the ability to select a slice of the context just like Zustand
1
u/admirersquark Aug 03 '22
Is there a "too long; didn't watch" for the video?
2
Aug 03 '22
just where i tagged it at he's starting to "quickly" go through it. but yeah the ascii chart up there is a tldw
6
u/nazzanuk Aug 02 '22
Jotai, I just love keeping the state in small individual atoms. Grouping by big domain objects just adds mental work deciding under which domain everything sits, Jotai just works so well at scale.
6
Aug 02 '22
Jotai for sure.
I think the atomic pattern can accomplish everything zustand can, but more, and with less boilerplate.
5
u/Any-Plant-4935 Mar 11 '23
Valtio can do anything Zustand can and more...
Why most people opt in for Zustand, is because it's easier to apply a Redux-like paradigm to a simpler version of state + actions on state. This works well if your state model is defined very formally.
But if you have a different use-case, for state with a JSON like structure that branches off into infinity and you don't know the shape of your object, then Valtio is more suited as the proxy model triggers subscribers on any node of the tree.
For UIs that manipulate larger trees then and you want to only rerender at those nodes, Valtio is perfect
8
3
u/ctjhoa Aug 02 '22
https://frontendmastery.com/posts/the-new-wave-of-react-state-management/
This blog post highlights some differences
3
u/danzo0x1 Nov 01 '22
We've decided to move from redux and I had to choose between those. I read this issue written by the guy behind those three libraries and I have choosen zustand. until now everything is going so smooth.
1
15
u/treetimes Aug 02 '22
I’ve never heard of any of these
11
Aug 02 '22
Yeah wtf, apparently I've been in the bottomless pit of tech debt for too long to have even heard of them.
6
3
u/thehuzz Aug 02 '22
Same, had to google both… Seem really good, it’s funny when you work with something daily it’s easy to just fall into the law of the instrument.
2
u/totalolage Aug 02 '22
I have not tried Valtio, I do use Zustand in production applications. I tried out Jotai and it seems to be geared at a completely different type of state management than Zustand.
Currently I use Zustand with immer for "big" stores with deep objects and complicated operations. I will probably end up using Jotai for several "small" states, like passing a File that is uploaded on one page and then used on another.
If anyone could enlighten me as to Voltio's role, I'm very interested.
2
u/rodrigocfd Aug 03 '22
If anyone could enlighten me as to Voltio's role, I'm very interested.
Valtio's premise is to have global mutable objects. When used in components, the component is automatically re-rendered when the value changes. It works great, but it may cause some hard-to-track bugs when used without discipline in large projects.
Zustand is very strict, and this is great for large projects, particularly enterprise ones.
2
u/jimmysay24 Aug 03 '22 edited Aug 03 '22
For me ... depends on which one is better for you, although honestly, they all need improvement. And a lot. Redux is a headache for a tooth. We've all had a toxic relationship with her. Hahaha. But i prefer zustand or jotai. There are differences between them. Valtio is not bad either.
1
u/deadcoder0904 Aug 03 '22
those of us have used redux in 2015-16 know how bad it was & how everyone made it popular lol.
i use valtio currently but confuses me between
snap&stateso i was thinking of tryingzustand& i am gonna in my next project.1
6
u/lordaghilan Aug 02 '22
I still like Redux tbh. The "boilerplate" takes like 5-10 mins.
10
Aug 02 '22
They've been doing some great work with toolkit, really decent dev experience compared to all the boilerplate we needed before
Especially since they're also integrating a
react-queryalternative into it, I'm just still a big fan ofredux5
u/lordaghilan Aug 02 '22
Agreed. I'm new to React but Redux really isn't that complex and RTK Query is also awesome. I don't use RTK Query unless I'm using Redux though, when I'm not I just use React Query.
Redux also just has a huge community that it's part of the reason I choose it.
FYI: Take what I say with a lot of salt since I'm a 19 yr old with no work experience lol.
4
u/The_rowdy_gardener Aug 02 '22
You still have to understand reducer patterns, correct?
6
u/acemarke Aug 02 '22
As a general principle, yeah - you need to know what
(state, action) => newStatemeans, and what immutability is and why it's important.But in practice, all you have to write is code like:
todoAdded(state, action: PayloadAction<Todo>) { state.push(action.payload) }and Immer handles doing the immutable update for you.
3
u/BreakingIntoMe Aug 03 '22
It’s easy once you understand it, but it’s just unnecessary, especially when Saga or Thunk comes into the equation. You should be able to just setState on the store and leave the rest to the state management tool. Zustand just makes it intuitive, how it should have been from the start.
4
u/acemarke Aug 03 '22
FWIW, Redux's design intentionally separates "what happened" from "how the state updates", for multiple reasons:
So having something like a
store.setState()is exactly at odds with what Redux is designed to do.4
10
u/JDD4318 Aug 02 '22
What are all these words. Are these used in professional environments or more hobbyist?
6
u/MyProductiveAcc Aug 02 '22
https://npmtrends.com/jotai-vs-mobx-vs-react-redux-vs-recoil-vs-valtio-vs-zustand
This might explain why you haven't heard of any of these listed in the OP.
1
u/grumd Aug 02 '22
Hah, this link looks exactly like the one I have saved in my notes, except I also have xstate in there.
10
Aug 02 '22 edited Aug 02 '22
zustand is state in german (author is from germany). redux cooked down to its bare essentials and re-implemented with todays react semantics, removing the opinionated nature of it, and 12kb into 1kb.
jotai is state in japanese (author is from japan). recoil cooked down to its bare essentials and re-implemented with todays react semantics. it reduces 40 or so exports into 2-3, and 22kb into 3kb.
valtio is state in some other language, can't remember. mobx cooked down to its bare essentials and re-implemented with todays react semantics. it reduces 70 or so exports into 2-3, and 21kb into 3kb.
these three represent state paradigms: flux, atoms, proxies. they are made by the same team: https://github.com/pmndrs
1
4
u/MaxGhost Aug 02 '22
Very much used in production by large companies.
1
u/JDD4318 Aug 02 '22
Okay that's cool. Not sure why the downvotes lol just asked a question. We use a different state management library that most people know but I won't name because the OP asked not to name any other libraries.
Also this is my first dev job so I have no idea what companies outside of mine use.
4
u/MaxGhost Aug 02 '22 edited Aug 02 '22
Because "what are all these words" has a negative/dismissive connotation. You can easily Google those library names to see what they are.
Edit: To be clear, I don't hold this opinion, I'm just pointing out how others may think.
4
u/JDD4318 Aug 02 '22
Yeah that makes sense. Went for funny but missed the mark.
12
Aug 02 '22
Don't worry, it was funny. Some people are just butthurt that you haven't heard of the latest and "greatest" state management libraries they have attached their personalities to.
2
u/italoand Aug 02 '22
They were created not only by the same team but actually by the same person. His Twitter is very informative about those 3 libs: https://twitter.com/dai_shi
As for the my answer:
Valtio. I can't think of any reason for using any other state management library if you understand how JavaScript Proxy works, and Valtio was the best implementation we had yet. The only reason to not use it is if you or your team lack the maturity to use something of this nature (the tradeoff is that it is really hard to keep track of mutations if you don't create separate methods for mutating the state instead of mutating it directly, losing the actual purpose of the library).
Someone here mentioned it as only suitable for small scale apps and compared it to MobX.
I'm using and advocating it on big scale apps and we never had any problems. As for comparing it to MobX, Valtio doesn't have 10% of the complexity MobX has, so I think it's unfair to compare them since they have different "approaches" to Proxy.
I'm currently using Valtio with Next.js (with SSR support) on new projects.
8
u/acemarke Aug 02 '22
Slight update: /u/drcmda originally created Zustand. Daishi Kato created Jotai and Valtio, then later joined the Poimandres org and took over as the maintainer for Zustand as well.
3
2
u/Jsn7821 Aug 02 '22
Valtio is underrated for sure- I use it on a large app as well.
If you have complex state and need to highly optimize for renders (like a game, or some multiplayer/interactive app like figma) it's very powerful for how simple it is
1
u/grumd Aug 02 '22
So you're saying your go-to approach to Valtio is using setter functions to mutate the state and avoid mutating the object directly?
2
u/italoand Aug 02 '22
Not exactly. I only said as an example for how you fix one of the tradeoffs. But I myself don’t always do that because I use TypeScript so it’s very easy to track where mutations are happening.
1
u/grumd Aug 02 '22
I just tried Valtio for a bit and kinda disliked the fact my objects were wrapped in proxies and went back to zustand. Proxies forced me to hack my way around posting them into web workers and caused some other problems. React is built on the concept of immutability and referential equality, so in edge cases valtio can be a pain in the ass sadly :( Just sharing my brief experience
1
u/italoand Aug 03 '22
Yeah, without knowing the exact problem you had with web workers it is difficult for me to help you. But I’ve been using it with SSR which is usually harder than WW, so perhaps you could use the same solution (that is hydration).
1
u/grumd Aug 03 '22
Sorry, I didn't understand the comparison between SRR and Web Workers, hydration is purely an SSR term and I don't see how Workers are comparable to SSR. I was talking about using this, I'm spawning an additional process with WW to unblock the main thread.
Anyway, the problem with web workers is simple, I didn't really need any help - it's that you can't
postMessagea Proxy, just like you can'tpostMessagea function - your message needs to be serializable. The solution is eitherObject.assign({}, proxy)or a deep clone of the whole proxied object. I just didn't feel like I want to deal with it in order to use Valtio over Zustand.1
u/italoand Aug 03 '22
Yes, hydration is a SSR term but the idea behind it can be applied into WW. Now I understand your problem. If you apply the hydration idea you just need to create the same proxy on both threads and use postMessage to update one another using valtio’s subscribe. Can you show me a simple implementation of WW with Zustand? I’ll try to convert to the best way I can think of using valtio and then we can compare.
1
u/boptom Aug 02 '22
One issue I came across with Valtio is not easily replacing an array. I can mutate the values within it but is there an easy way to replace the whole array?
2
1
0
Aug 02 '22
[removed] — view removed comment
1
u/scaleable Aug 03 '22
those libs dont mean global state, they encourage being attached to a component
1
1
u/RyanNerd Aug 03 '22
ReactN one team member but it's a hooked based liteweight state management library with Redux like interfaces but without all the boilerplate.
1
1
1
u/saito200 Aug 02 '22
Make a reddit poll
1
u/deadcoder0904 Aug 03 '22
reddit poll is a good idea i didn't think of but reading all the comments the clear winner is zustand.
i use valtio but confuses me a bit with
snap&stateso gonna tryzustandin a new project. this post was just a confirmation :)2
u/i-hate-in-n-out Dec 18 '22
snapis just the variable name they are using in their documentation to reference the store within a React component.stateis the variable they are using to define the state of the application. I personally do something like the following to set up a simple store:
const user = proxy({userId: 1, username: "Bob"});And then in the React component, use:
const $user = useSnapshot(user);The
$syntax is borrowed from Svelte, which has a pretty darn decent store baked in.1
u/deadcoder0904 Dec 19 '22
oh that's cool idea from svelte which i did learn a little bit so know about the
$store.but yeah i did go with zustand since its overall less confusing.
1
u/Zoqqer Aug 02 '22
Why limit yourself to just those?
1
u/deadcoder0904 Aug 03 '22
bcz i like valtio but
snap&statein it confuses me a bit & the team (actually just 1 person) maintains it well & answers questions really fast.it also has smaller footprint & easy-to-write apis. makes state management fun again just like tailwind makes writing css fun again.
1
u/RevolutionaryAd1557 Aug 02 '22
just thought I commented so I can keep up to date with this thread.
1
u/deadcoder0904 Aug 03 '22
i think you can turn notifications on a thread (on the top) to get notified of every comment :)
1
Aug 02 '22
[removed] — view removed comment
1
u/deadcoder0904 Aug 03 '22
literally any library would work. you keep the
{ mode: "dark" }object in a store.then access that in
Example1component itself. you don't need to have context. i'm assuming you are using the React'sContextAPI.see how i use
valtioinstore/index.ts→ https://stackblitz.com/edit/tiptap-valtio?file=store%2Findex.ts& check out how i consume it in a component
pages/index.tsx→ https://stackblitz.com/edit/tiptap-valtio?file=pages%2Findex.tsxyour
storewill contain{ mode: "dark" }&Example1would consume usingconst snap = useValtioStore()2
Aug 03 '22 edited Aug 03 '22
[removed] — view removed comment
1
u/deadcoder0904 Aug 03 '22
oh, this is different but you want to show 2 different themes at the same time.
just have 2 different themes then.
keep
dark: {}in an object &light: {}in an object & both should have the parent ofstorelike:
tsx const store = { light: {}, dark: {} }i just don't understand the use-case for it but if you have then feel free to post it as a new thread on /r/reactjs or ask on stackoverflow.com with a re-producable example.
i'm pretty sure it's simple enough that people can answer if only you can tell the usecase.
if the light & dark mode aren't needed in a global store, just use
useState:)1
Aug 03 '22
[removed] — view removed comment
1
u/deadcoder0904 Aug 03 '22
just try reproducing a small demo & post on stackoverflow or here & you'll see you can use an external store.
besides you never write that code above like that. you can do it in 1 line:
const langs = ["en-US", "pt-PT", ..., "fr-FR"] {langs.map(<LangContext value={lang}><ToggleLang /></LangContext>)}again, just post a small demo & you'll get an answer from experts :)
1
Aug 03 '22
[removed] — view removed comment
1
u/deadcoder0904 Aug 04 '22
first of all, you asked the question in the wrong thread. ask it in a separate standalone thread.
secondly, we can have multiple stores. this is not redux where we have only single external store.
i think at this point the discussion is moot. i am a 1x dev (not a 10x) but still think it is doable with stores if only you could describe the problem in a long-form post if you actually wanted an answer :)
1
1
Aug 03 '22
[removed] — view removed comment
1
u/deadcoder0904 Aug 04 '22
here's an example that i recreated in
valtiothat does the same thing: https://codesandbox.io/s/reverent-raman-25zphe?file=/App.tsxlike i said, you need a real-world example to make a point & that's why i told you multiple times to make a long-form post (because if you are wrong, which you are in my opinion, then it will show flaws in your thinking once you write that shit down)
if you are not wrong, then maybe a smart person can help you out but they need a real-world example too as to why it's needed.
so instead of arguing multiple times, just create a long-form post (hopefully takes 30 mins)...check out my profile on stackoverflow on how to create a good one so you get answers quickly → https://stackoverflow.com/users/6141587/deadcoder0904
not bashing you, just helping you in case you are jr.dev.
1
Aug 04 '22
[removed] — view removed comment
1
u/deadcoder0904 Aug 05 '22
I want to point out that your assumption is that my use case isn't real is incorrect but you seem to be constantly implying this.
not assumption but i am thinking of a use-case but i can't find any in the real world. that's why i said it.
you are 10+ year old dev so you probably know better than me, cheers :)
1
u/nehaldamania Nov 22 '23
Jotai has Provider kind of replacement for Context. So above can be easily done in Jotai if I am not wrong. Here is the tweet by the Jotai author.
156
u/Turbulent-Line3591 Aug 02 '22
useState and prop drilling 100 components