Combining Zustand with React Query

VSCode Theme | Font → Material Theme Darker | Menlo, Monaco "monospace"

In this video I will show you the correct way to combine Zustand with React Query, two very popular libraries that don't even need to be combined together because of how good they are! But they definitely can if you need them to. Just be careful because there is a right way to do it, and a wrong way to do it. I will show you both.

[pedroserapio]

Much appreciated. I started implementing React Query on top of Zustand and started to think, why this sounds like duplicating data. Great and simple explanation.

[johndevnoza]

as an entry level developer, with no work experience, i got that part at the very begining when i tryed tanstack query. i guess now i can be proud! :D great channel btw

[yakuznecov]

Спасибо большое за великолепный урок. Я долго искал реализацию этой задачи, что бы просто было. И вы объяснили как нельзя лучше. Видно, что у вас огромный опыт. Успехов каналу в развитии.

[giorgos]

The useEffect would be necessary if these data needed to be more global. In this example you just display them in the same component.

[socaseinpoint]

Wow, that's exactly what i was doing, but you make it even more clear! Thanks!

[the_saliheen]

Splitting the state into client and server adds another level of complexity for the component itself. Now your component has to differentiate between the two types, and it basically binds the two state types which imo is also a weird pattern.

One can argue that the filter params are also a "server" state because that's how your server knows which data to return! And you see how it can be a point for argumentation within teams.

Instead, what I'd do is decide to come up with the single "data" state which overlooks everything "under the hood" and exposes the data to the component, so the component itself can be less confusing and be cleaner.

So in this example, Zustand can be a single point of reference for the component with its hooks, while the React Query can be encapsulated inside of Zustand's implementation.

This way the component is really a presentational view component that doesn't know about "server" and "client". The result is a simpler code:
Component <- State <- Server.

[GameKornel]

Be careful with calling zustand this way. To properly "tree-shake" it you need to go with const data = useStore((state) => state.data), not just const { data } = useStore().
Anyway great video!

[ronylev-ari]

Awesome tutorial. I rarely get to watch ones that are oriented towards real projects and touch on architecturing your application using the target tools and aiming to establish best practices.

[gauravraj]

Great video! However, instead of managing the filters using client state, I suggest using URL parameters. This approach helps in sharing URLs with specific filter settings, making it easier for users to bookmark or share filtered views.

[jsvrs]

Can't wait for the next video: Combining Redux with Zustand and React Query

[rjwhite]

on the website the example they have is they make 2 types, one describing state and the other type describing actions then create the store saying create<State & Action>. It might be overkill but I thought it helped make the code a little easier to read. Especially if their are more than one actions assigned to a state.

[geforcesong]

I have to say this is true for normal cases like you described. For some other cases, you must put the users to zustand by useEffect and make changes for client. For example, in the user list, you need display an active column with checkbox, and you can check/uncheck the checkbox then submit the changes. Imagine that you have more other fields need do the same. In these cases, you have to put the users to zustand firstly by useEffect, there is no good way to implement this with react query only.

[ishandeveloper]

I liked the explanation, really crisp! However, my only concern is this that in case let's say this is supposed to be a shared global state within a big app. Let's say you're planning to store user's profile data or auth for a simpler example. Having a zustand store, from which you can retrieve the state value in any other component feels like a much more better approach, rather than adding react-query everywhere. Would love to know other opinions and thoughts?

[lzyphil]

Hello, Could you please tell what plugin allows you to have the autocompletion code ? it looks really smart to know exactly what you want to code

[linqusik]

How have you done this beautiful cursor animation?

[BowangLan]

I think the two solutions proposed in this video are trying to solve different problems. The first solution, storing users directly in zustand, is often used (for me at least) when you need to make “data” from react query globally accessible. The second solution is simply trying to add extra filtering states in addition to users and pass them to the backend API.

[mDHARYL]

This is what I've been looking 😊 thank you

[MosesZhao-sppg]

Great Video! But I do want to ask what should we do if need to fetch the data that we got with react query globally? Thank!

[otis]

and what if we need state mutations in the data, dont we need to keep the client state for that ??

[hey_you_]

thanks for this info, it would be great to have a better demo using several server components and client components "use client"/"use server" etc... that way we can see the flow and possible errors