Zustand with Context API - An Advanced Pattern

[@markdeguzman7760]

This is what I was thinking a few days ago, thank you.

[@hassanad94]

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!

[@OusmanDiallo-d4f]

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

[@n00berdoober]

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 💯🙌

[@AqibRime]

I was searching this solution for a long time. Thanks for the video

[@nikola-dev]

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.

[@thanathep_lamp]

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?

[@ViacheslavUstinov-g4x]

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

[@hikmetmelik]

Thank you for video and giving perspective

[@odogwu-1918]

use this concept and create a multi step form in next js for a section of a form

[@PaulSebastianM]

So basically doing dependency injection with Context acting as factory as well as DI container.

[@Deus-lo-Vuilt]

Thank you, very good content

[@HBMoulvad]

What if you want to access the store in a function outside a component?

[@133289ify]

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

[@MohamedDOURAI]

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.

[@mosesolayinks6361]

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.

[@developaul]

Context is not a state manager, it is just an injector of dependency

[@AbdurRahim-eu3zr]

Then why do we need zustand at first place as we can do this with simple context api

[@salok1508]

+1

[@zayne-sarutobi]

Context doesn't manage state, it's just a data transport mechanism

[@AbdurRahim-eu3zr]

@@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

[@zayne-sarutobi]

@@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

[@harag9]

Great video. I heard about Jotai the other day. Can you do a video on explaining zustand vs jotai ? pro/cons etc.

[@theintjengineer]

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.

[@nykid30]

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.

[@theintjengineer]

@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.

[@moustafamahmoud4948]

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 ?

[@MagerX1794]

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

[@saqomelqon1618]

We’re back to a lot of boilerplate in redux 😅

[@princenarteh8822]

Nice tutorial. But what if the data comes from API? How do you set it using the method?

[@Dead_Code2511]

What's the usefulness of Zustand in this case?

[@hassansadrati8421]

Does this patern will work as expected if initial data fetched from api using react query ?

[@nykid30]

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

[@leularia]

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.

[@zayne-sarutobi]

With Zustand, you still retain ability to use selectors to cut down unnecessary rerenders

[@chess4964]

​@@zayne-sarutobiJust use the use-context-selector for this case you dont need to combine zustand with Context api.

[@zayne-sarutobi]

@@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

[@chess4964]

@@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.

[@CodeCodeCode-ts9bc]

Hundreds of usage... Making customs services, making custom components etc. Our very large project depends on this pattern.

[@razorxxxiv5884]

Can someone explain to me in great details why use redux over zustand in react?

[@Cypekeh]

zustand is pronounced as "tsu shtand"

[@sidalisaadi1961]

Great video! Can this also work if I want to set the initial state through an http request?

[@MrEnsiferum77]

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....

[@allaithbitar1199]

And now you've got redux basically

[@micortes89]

This looks too complicated for me to use 😢

[@kennethlau8108]

First🎉

[@codernerd7076]

Wouldn't it be easier to just use Redux which has proven to work well?! 🤔

[@n00berdoober]

One eternity older product, also I think zustand is more simpler than redux's reducer and dispatcher setup

[@cosdensolutions]

Has the same problems! Would be the same solution