Watching your videos makes me realize, how I actually don't know anything. Before this video, I never actually thought of this limitations of zustand. As a good developer we should implement abstraction. Thanks 💯🙌
I am glad to see this new pattern. But it's overcomplication in order to have passing props directly to zustand store. There should be way to set this "props" in zustand store before becomes "props". Which means, this data comes from API, or somewhere from UI local state, you can simply put it in zustand store when fetch data or in some component if its local ui state, and than no need to pass it as props at all, just pull it from zustand. Also, you should try it out to see how simple it is to use Jest or Vitest with Zustand. Its very simple and nice dev experaince.
Thank you!!! Genius :D It opens up so much things... I will use it, and i will be able to writte better and more reliable code with this pattern!!! Thank you again!
i still dont understand... if we're going to do all of this why not just skip the zustand implementation altogther and just implement this with the context api
at least without zustand you won't be able to sign on specific fields and will have rerenders every time with simple useContext + you won't have access to zustand store methods like reset store for instance
I used combinations of useContext, but with redux when I needed to solve problems with redrawing a complex interface. Although the experience had a positive result, I gradually removed it from the project because the complexity of understanding the code grew too much. Thanks for your pattern, but I think it is better to avoid using context in a project and modern state managers at the same time
I am really trying to get into React, basically because of the nice ShadcnUI lib, but as much as Angular has a steeper learning curve, things like these just don't exist there. Stuff there is more organised. And I like it. I understood the video up to the selector thingy part. PS: I'm not saying the video is bad. Maybe I should have delved deeper into Zustand, or maybe I'm just too stupid. I don't know.
You're not stupid, this pattern is. 100% zero reason for it to exist except for bad developers trying to shoehorn a solution into something to work with their bad architecture.
@nykid30, thanks for the reply. I was here like: no way this is "the good/a proper way of doing things." So convoluted and unorganised. But then, the guy is an expert, so I thought it could be just my skill issue, but seeing that other devs also find it somewhat "strange" makes me feel a bit more relieved😅. Cheers.
@theintjengineer honestly, influencer devs I feel arent the best people to learn from. A lot of them promote really weird stuff that you wouldnt normally do if you've been working at a company. I guess the best we can do is see their proposal, understand the use-case and then evaluate ourselves if it is actually meaningful or not instead of just taking what they say as god-tier tips
Great video! I have a question though. I normally create an action to initialize the data in zustand, for example, I set the count state as null, then I create an action called setCount, that would initialize the count state when I receive the data either from the server or through props, is this bad? Also you mentioned that this solution is useful for making the state available only for the relevant components we desire by wrapping them around the context, but wouldn't that state be lost in case the page refreshes, shouldn't there be a persistence solution for this? I would appreciate it if you could (if you have some time) to make a video for persisting state and other zustand options.
@@aleksandarspasov6815 I've already done it, it's just that I start to wonder if my implementation is wrong, has some flaws or maybe could be improved in some way I don't know about.
You dont need this pattern. If you initialize from remote, just set zustand to whatever default values you want and then update it when the data arrives. If you're hydrating, you can still do the same, except just initialize zustand with that data directly. If youre using context api (by itself), then you do the exact same thing. Zero need to combine them and overcomplicate things
I have a question. I'm using Apollo Client to fetch data from a GraphQL API, so it's hook-based. Is it possible to implement a Zustand context action, like calling an action to fetch data from GraphQL?
@@zayne-sarutobi If we are doing it this way with Zustand, it’s essentially the same as using useState. The purpose of using Zustand is to avoid context provider or similar providers like Redux
@@AbdurRahim-eu3zr Nope, it's not the same With Zustand, you still retain the ability to prevent unnecessary rerenders by way of selectors... With useState, you don't
I think many still don't know that Context API is purely there to simplify prop drilling. It's actually re-rendering the whole components tree it's wrapping upon every state change. It can in fact solve your (global) state management issues but there's a cost.
A really good question! The pattern seems sound but what is the real use case of the pattern he showed?! When do we actually need to initialise the store with data other then when it's come from API?!
As you saw in the video when he initialised the Context Provider state he completely ignored the setter. There's no need to use this setter, which would in fact re-render the whole components tree this context is wrapping. You can use the Zustand store itself to change the state and it will re-render only the components that are subscribed to it.
As we know context API is not working fine with rapidly changing states, in this example do we have this concern since we access zustand through context api or not ?
The context isnt actually changing here, which is what context has issues with doing effectively. In this scenario you're passing the zustand object to context, and it passes it down as you need. The reference to the state will not change, therefore context will not re-render
hmm...uhhhm... so if you happen to initialize your state like this you probably want to consider using React local state instead. If the initial prop is coming from the network you'd still want to show a default value/view to the user whether you choose to have zustand or not
What's the use of zustand in that case just use useState and useReducer no need for zustand, zustand is created for a global state i don't see any use here.
@@chess4964 Now that's just pointless isn't it? If I'm already using zustand for most stuff, why pull in an extra lib(which also means increased bundle size) just for that one usecase? Let's not forget that zustand v5 is just half a kilobyte, so if I can do practically everything with it, I should
@@zayne-sarutobi well what im trying to say if you use Context Api you should use the package what I recommended since it is used to reduce rerenders when using context api and ditch zustand not the other way around.
Redux has become a full package deal so one could see this as an advantage - it solves the global state and fetch issues. Zustand is purely global state management tool. But to answer your question - there's very little or absolutely no reason to use redux over Zustand (+ React Query).
@aleksandarspasov6815 there is a very annoying issue with redux and nextjs that when you change the store code it doesnt update until you trigger a clean full build because it gets cached and that issue used to make me go crazy all the time debugging everywhere and it is just redux being redux.
Zustand with context api is confusing, u never know where to put the provider and that can change and maybe u lift the provider up, makes other components rerender for no reason... I prefer slices per page (still u have atomic selectors, just longer), sometimes u will need state value from different sources.... this is terrible pattern....
Watching your videos makes me realize, how I actually don't know anything.
Before this video, I never actually thought of this limitations of zustand. As a good developer we should implement abstraction.
Thanks 💯🙌
You think u don't know anything, I am still thinking what is the use of zustand even after watching the video.
@@aaqibhamdule73 😂😂. I also did not know zustand 3 months back
This is what I was thinking a few days ago, thank you.
I am glad to see this new pattern. But it's overcomplication in order to have passing props directly to zustand store. There should be way to set this "props" in zustand store before becomes "props".
Which means, this data comes from API, or somewhere from UI local state, you can simply put it in zustand store when fetch data or in some component if its local ui state, and than no need to pass it as props at all, just pull it from zustand.
Also, you should try it out to see how simple it is to use Jest or Vitest with Zustand. Its very simple and nice dev experaince.
Thank you!!! Genius :D It opens up so much things... I will use it, and i will be able to writte better and more reliable code with this pattern!!! Thank you again!
i still dont understand... if we're going to do all of this why not just skip the zustand implementation altogther and just implement this with the context api
at least without zustand you won't be able to sign on specific fields and will have rerenders every time with simple useContext + you won't have access to zustand store methods like reset store for instance
@@ЕгорЕсипенко-б5ч key point for this pattern, you just pass a singleton of zustand store to the context, it nearly never to change.
I was searching this solution for a long time. Thanks for the video
I used combinations of useContext, but with redux when I needed to solve problems with redrawing a complex interface. Although the experience had a positive result, I gradually removed it from the project because the complexity of understanding the code grew too much. Thanks for your pattern, but I think it is better to avoid using context in a project and modern state managers at the same time
We’re back to a lot of boilerplate in redux 😅
Great video. I heard about Jotai the other day. Can you do a video on explaining zustand vs jotai ? pro/cons etc.
So basically doing dependency injection with Context acting as factory as well as DI container.
And now you've got redux basically
I am really trying to get into React, basically because of the nice ShadcnUI lib, but as much as Angular has a steeper learning curve, things like these just don't exist there. Stuff there is more organised. And I like it.
I understood the video up to the selector thingy part.
PS: I'm not saying the video is bad. Maybe I should have delved deeper into Zustand, or maybe I'm just too stupid. I don't know.
You're not stupid, this pattern is. 100% zero reason for it to exist except for bad developers trying to shoehorn a solution into something to work with their bad architecture.
@nykid30, thanks for the reply.
I was here like: no way this is "the good/a proper way of doing things."
So convoluted and unorganised. But then, the guy is an expert, so I thought it could be just my skill issue, but seeing that other devs also find it somewhat "strange" makes me feel a bit more relieved😅.
Cheers.
@theintjengineer honestly, influencer devs I feel arent the best people to learn from. A lot of them promote really weird stuff that you wouldnt normally do if you've been working at a company. I guess the best we can do is see their proposal, understand the use-case and then evaluate ourselves if it is actually meaningful or not instead of just taking what they say as god-tier tips
Great video! I have a question though. I normally create an action to initialize the data in zustand, for example, I set the count state as null, then I create an action called setCount, that would initialize the count state when I receive the data either from the server or through props, is this bad?
Also you mentioned that this solution is useful for making the state available only for the relevant components we desire by wrapping them around the context, but wouldn't that state be lost in case the page refreshes, shouldn't there be a persistence solution for this?
I would appreciate it if you could (if you have some time) to make a video for persisting state and other zustand options.
You need to *persist* data. Zustand offers this middleware as well, just checkout their docs.
@@aleksandarspasov6815 I've already done it, it's just that I start to wonder if my implementation is wrong, has some flaws or maybe could be improved in some way I don't know about.
Thank you for video and giving perspective
Does this patern will work as expected if initial data fetched from api using react query ?
You dont need this pattern. If you initialize from remote, just set zustand to whatever default values you want and then update it when the data arrives. If you're hydrating, you can still do the same, except just initialize zustand with that data directly.
If youre using context api (by itself), then you do the exact same thing. Zero need to combine them and overcomplicate things
Great video!
Can this also work if I want to set the initial state through an http request?
I have a question. I'm using Apollo Client to fetch data from a GraphQL API, so it's hook-based. Is it possible to implement a Zustand context action, like calling an action to fetch data from GraphQL?
Then why do we need zustand at first place as we can do this with simple context api
+1
Context doesn't manage state, it's just a data transport mechanism
@@zayne-sarutobi If we are doing it this way with Zustand, it’s essentially the same as using useState. The purpose of using Zustand is to avoid context provider or similar providers like Redux
@@AbdurRahim-eu3zr Nope, it's not the same
With Zustand, you still retain the ability to prevent unnecessary rerenders by way of selectors...
With useState, you don't
I think many still don't know that Context API is purely there to simplify prop drilling. It's actually re-rendering the whole components tree it's wrapping upon every state change.
It can in fact solve your (global) state management issues but there's a cost.
Nice tutorial. But what if the data comes from API? How do you set it using the method?
A really good question! The pattern seems sound but what is the real use case of the pattern he showed?! When do we actually need to initialise the store with data other then when it's come from API?!
Thank you, very good content
What's the usefulness of Zustand in this case?
As you saw in the video when he initialised the Context Provider state he completely ignored the setter. There's no need to use this setter, which would in fact re-render the whole components tree this context is wrapping. You can use the Zustand store itself to change the state and it will re-render only the components that are subscribed to it.
As we know context API is not working fine with rapidly changing states, in this example do we have this concern since we access zustand through context api or not ?
The context isnt actually changing here, which is what context has issues with doing effectively. In this scenario you're passing the zustand object to context, and it passes it down as you need. The reference to the state will not change, therefore context will not re-render
What if you want to access the store in a function outside a component?
Make that function a *pure* one and pass the store as an argument. It will also make it immensely easier to test.
zustand is pronounced as "tsu shtand"
use this concept and create a multi step form in next js for a section of a form
hmm...uhhhm... so if you happen to initialize your state like this you probably want to consider using React local state instead.
If the initial prop is coming from the network you'd still want to show a default value/view to the user whether you choose to have zustand or not
Exactly! Not really a good use case for this pattern. One should stick to default state.
What's the use of zustand in that case just use useState and useReducer no need for zustand, zustand is created for a global state i don't see any use here.
With Zustand, you still retain ability to use selectors to cut down unnecessary rerenders
@@zayne-sarutobiJust use the use-context-selector for this case you dont need to combine zustand with Context api.
@@chess4964 Now that's just pointless isn't it? If I'm already using zustand for most stuff, why pull in an extra lib(which also means increased bundle size) just for that one usecase? Let's not forget that zustand v5 is just half a kilobyte, so if I can do practically everything with it, I should
@@zayne-sarutobi well what im trying to say if you use Context Api you should use the package what I recommended since it is used to reduce rerenders when using context api and ditch zustand not the other way around.
Hundreds of usage... Making customs services, making custom components etc. Our very large project depends on this pattern.
Is this not counter intuitive to the need for Zustand in the first place ? Zustand is supposed to help reduce the re-render issues of context api.
Context is not a state manager, it is just an injector of dependency
Can someone explain to me in great details why use redux over zustand in react?
Redux has become a full package deal so one could see this as an advantage - it solves the global state and fetch issues. Zustand is purely global state management tool.
But to answer your question - there's very little or absolutely no reason to use redux over Zustand (+ React Query).
@aleksandarspasov6815 there is a very annoying issue with redux and nextjs that when you change the store code it doesnt update until you trigger a clean full build because it gets cached and that issue used to make me go crazy all the time debugging everywhere and it is just redux being redux.
Zustand with context api is confusing, u never know where to put the provider and that can change and maybe u lift the provider up, makes other components rerender for no reason... I prefer slices per page (still u have atomic selectors, just longer), sometimes u will need state value from different sources.... this is terrible pattern....
This looks too complicated for me to use 😢
just seen this kind of useState with Context api in Claude Sonnet😅
Wouldn't it be easier to just use Redux which has proven to work well?! 🤔
One eternity older product, also I think zustand is more simpler than redux's reducer and dispatcher setup
Has the same problems! Would be the same solution
First🎉