I have decided not to let the never-ending topic of state management in React overwhelm me. I have chosen to use React-Query for server state management and Zustand for the rest. This makes my life simpler.
What do you mean by "the rest"? How do you distinguish between local and global state? And what about state boundary (reset state after a specific component is unmounted)?
@@adamzalesak I'm not aware of every type of state that might exist in a react application, but at my current level, I do know that there is the server state and the client state; so in my comment, "the rest" was referring to the client state that includes the global state that doesn't depend on data from the server. In my opinion, every state that is only used inside a component to manage its internal data is a local state. If at any point another component in the application has to be aware of that state, I turn it into a global state, and voila. State boundary, 🤔I do not have any experience with that, so I'm still thinking 😅
I am using this approach to manage my global state with react-query, No need of React Context, or another library like Zustand. With only these 2 files and calling in consumer components, let me have the data in single source of truth. Thanks for the video!
React-query is an awesome piece of tech, i'm a big fan of tanner and his crew... but using RQ like a global state management looks like a workaround, maybe it's better to use libs that were made for this purpose, like zustand, mobx and so on
Hey there Cosden! This is how we manage our state in our company. One thing though, react query has a default cache time of 5 minutes, that means the data will be erased from the cache after that time, shouldn't we add a cacheTime: Infinity to the configuration params? Great video.
Isn't the default cache time for React Query 5 minutes? If you want to use this strategy, wouldn't you need to set an infinite cache time to prevent data loss?
What are the benefits of this? It seems like it's functionally just a global context provider, since the features specific to React Query are disabled explicitly.
@@mrshambhuthapa data is not persisted between page refreshes if that's what you mean Between react context and RQ the only benefit is the improved way of handling the data updates. Apart from that I don't see a clear benefit and if you really need global state I guess there are better options that are meant for that like valtion, zustand or jotai
Do you know it handle cache management for API. So if you has same component in multiple screen and it hit the API every time you visit the screen when you didnt use react-query which is not good especially when you have thousands or millions of users, your server will definitely be overloaded, that's where cache management is needed, for which react-query provides that solution, and there are many other benefits.
Sir, can we import custom hooks dynamically? When I try to import a custom hook dynamically, it gives me an error because it doesn't detect the imports used inside the custom hook.
Please don’t do this. This is becoming a really big mess really quickly. Yes it works, but that’s the same as using a war tank to go to mall, you’ll get there sometime, but why?
I think it will rerender, and i think it will also behavior like useState or reducer when the state change it will rerender
6 месяцев назад
I don't really see the use in the if I'm being honest. That being said, it's a cool DX - and a nice exercise in generics and hook factories. I'd maybe look into just recreating signals or using custom events or something to recreate a global state solution instead so you can see how you don't really need that stuff from react query. All you need is a list of listeners and a way for them to subscribe to the state. Another thing you might have failed to consider is how this is (kind of unnessecarily) polluting react query's keys. It's cumbersome to maintain unique keys for every state if this is used actively, and especially not mixing those keys with existing query keys used in the query client for actual queries. Imagine also having a user query somewhere with the same "users" query key.
Can you make a video on event driven design with event emitter on react where we can pass events from one component and catch event in another. Thanks 😄
Hey cosden, I have been working on javascript for the past 3 years, i used to write better code but iam always afraid of using typescript especially when integrating and using other 3rd party libraries or modules, Because I have to use their types which makes me Little afraid, so do u have any suggestions on this
I see what you’re doing, but this seems like an insane approach… React Query is an _asynchronous_ state management library, so I’m not sure it’s great for this use case.
I am trying to use react query to deal with API fetches and at the same time I need to store the data from the backend in states since there are a lot of changes that the user should be able to perform before sending the manipulated data to get updated in the backend. I'm currently just fetching the data with react query and saving the results in states inside of context API providers. I feel like I'm doing something wrong. Has anyone gone through the same? (next js 14 app) I didnt know I could achieve something familiar with react query.
Why doing this when you have other state management solutions that were actually created with that purpose... I mean, I don't believe this offers any benefits and it's just a lot of unnecessary boilerplate. Idk, even TKDodo, the TanStack query mantainer recommends using this library only for async state and server state, and leave client state for libraries such as Zustand
I have decided not to let the never-ending topic of state management in React overwhelm me. I have chosen to use React-Query for server state management and Zustand for the rest. This makes my life simpler.
What do you mean by "the rest"? How do you distinguish between local and global state? And what about state boundary (reset state after a specific component is unmounted)?
@@adamzalesak I'm not aware of every type of state that might exist in a react application, but at my current level, I do know that there is the server state and the client state; so in my comment, "the rest" was referring to the client state that includes the global state that doesn't depend on data from the server. In my opinion, every state that is only used inside a component to manage its internal data is a local state. If at any point another component in the application has to be aware of that state, I turn it into a global state, and voila. State boundary, 🤔I do not have any experience with that, so I'm still thinking 😅
@@johng.weller468 great answer
agreed, react-query for server, zustand for client global state, and just use context/state for component scoped state,
I do exactly same and i think it is because im a begginer and always looking for short and easy way.
react-query is truly a blessing for react community.
I am using this approach to manage my global state with react-query, No need of React Context, or another library like Zustand. With only these 2 files and calling in consumer components, let me have the data in single source of truth. Thanks for the video!
Cosden deserves a million subs. Big Ws man
Eyyyyyy,codsens arguably first sponsor,congratulations🎉
React-query is an awesome piece of tech, i'm a big fan of tanner and his crew... but using RQ like a global state management looks like a workaround, maybe it's better to use libs that were made for this purpose, like zustand, mobx and so on
Splendid, and your course project react was great as well :)
Hey there Cosden!
This is how we manage our state in our company. One thing though, react query has a default cache time of 5 minutes, that means the data will be erased from the cache after that time, shouldn't we add a cacheTime: Infinity to the configuration params?
Great video.
yes we should! :D
Wow that's great! Updating your react query to v5 would also be a blast!
Would the code be different?
@@jsward17 it's not backward compatible
Wow I will use this approach for sure. Thanks
I wanna watch every video of this channel and i am going to, this is premium content ❤
Ppl talk too much about React Query + zustand, but then realize they become Redux toolkit technically 😂
yep
Why not use react-intl to store global constants? Or maybe msw to handle data manipulation? Even better, jest assertions to validate forms?
Isn't the default cache time for React Query 5 minutes? If you want to use this strategy, wouldn't you need to set an infinite cache time to prevent data loss?
good catch, yes!
What are the benefits of this? It seems like it's functionally just a global context provider, since the features specific to React Query are disabled explicitly.
Data remains there on the state after refresh
@@mrshambhuthapa data is not persisted between page refreshes if that's what you mean
Between react context and RQ the only benefit is the improved way of handling the data updates. Apart from that I don't see a clear benefit and if you really need global state I guess there are better options that are meant for that like valtion, zustand or jotai
@@sebastianlpoliak just use zustand its better than redux and this query shit
Do you know it handle cache management for API. So if you has same component in multiple screen and it hit the API every time you visit the screen when you didnt use react-query which is not good especially when you have thousands or millions of users, your server will definitely be overloaded, that's where cache management is needed, for which react-query provides that solution, and there are many other benefits.
What happens if the user updates the state and then refreshes the browser?
Can context api be replaced by this?
Sir, can we import custom hooks dynamically? When I try to import a custom hook dynamically, it gives me an error because it doesn't detect the imports used inside the custom hook.
nope, custom hooks need to be known at render time. And they can't change order from one render to the next
it doesn't come from tanstack, it comes from heaven😮
Please don’t do this. This is becoming a really big mess really quickly. Yes it works, but that’s the same as using a war tank to go to mall, you’ll get there sometime, but why?
From past days i was looking for it how i can use it to manage data
Does it support subscriptions or selectors similar to Zustand? I mean we need to nofity other components when a certain slice of state changes.
I think it will rerender, and i think it will also behavior like useState or reducer when the state change it will rerender
I don't really see the use in the if I'm being honest. That being said, it's a cool DX - and a nice exercise in generics and hook factories. I'd maybe look into just recreating signals or using custom events or something to recreate a global state solution instead so you can see how you don't really need that stuff from react query. All you need is a list of listeners and a way for them to subscribe to the state.
Another thing you might have failed to consider is how this is (kind of unnessecarily) polluting react query's keys. It's cumbersome to maintain unique keys for every state if this is used actively, and especially not mixing those keys with existing query keys used in the query client for actual queries. Imagine also having a user query somewhere with the same "users" query key.
I realized that with this comment. Thanks
Can you make a video on event driven design with event emitter on react where we can pass events from one component and catch event in another. Thanks 😄
broo do you have react projects in your course ??
the whole course is one big project so yes :D
bro, i watch your videos on a tv. the font-size is soooo small
Hey cosden, I have been working on javascript for the past 3 years, i used to write better code but iam always afraid of using typescript especially when integrating and using other 3rd party libraries or modules,
Because I have to use their types which makes me Little afraid, so do u have any suggestions on this
"zustand hates this one simple trick"
Some videos about nextjs please
I see what you’re doing, but this seems like an insane approach… React Query is an _asynchronous_ state management library, so I’m not sure it’s great for this use case.
I am trying to use react query to deal with API fetches and at the same time I need to store the data from the backend in states since there are a lot of changes that the user should be able to perform before sending the manipulated data to get updated in the backend. I'm currently just fetching the data with react query and saving the results in states inside of context API providers. I feel like I'm doing something wrong. Has anyone gone through the same? (next js 14 app)
I didnt know I could achieve something familiar with react query.
React query caches data by default, that's why it asks for a query key
I think you don't need to use useState in this case, just use the data the RQ returns
why would I use react if I need a 3rd party library for everything...
Why doing this when you have other state management solutions that were actually created with that purpose... I mean, I don't believe this offers any benefits and it's just a lot of unnecessary boilerplate. Idk, even TKDodo, the TanStack query mantainer recommends using this library only for async state and server state, and leave client state for libraries such as Zustand
Nice video. But React query is one of the most used and well liked state management solutions for react. Its not underrated in any way
why don't you just make the type of the "queryKey" also a generic type instead of uknown?
Jotai && Zustand && TanStack Query
Closure
❤
What if we want to persist some of the data
super long briliant ad
Disabling the default behavior of @tanstack/query indicates that you are abusing the library as state manager.
nope, I disable that behavior all the time even just for fetching. It's meant to be configurable