what makes that video great, is, that you compare the "old" and "react query" way! I clearle can see and understand the advantages of react query now. thx!
your example can be improved even further if you create custom hooks on top of the useQuery hook, like, you could create a useProductsQuery hook and use it instead of the regular useQuery hook and have even less code repetition because of that
Can you give me a code example for that? I don't see a way that you can simplify it even more since we're getting data and isLoading and error from the useQuery hook.
If you focus on the react query 3:53 part of the video (it says there is almost no difference between `useEffect` and `the query` when it comes to performance). The main reasons are for easier, more readable and maintainable code and eliminating the need for a global store like Redux (at least for the server-side data).
Yes exactly! It's important for developers to understand that these libraries use useEffect. However, encapsulating your API logic in a hook that uses useEffect (which is what React Query does) is a good idea in my opinion.
As for me, one of the most convenient ways to separate logic of api calls and the following data processing is using redux-saga effects, and it's very good both in terms of code structuring and readability.
@@StamyIIReturn I don't think there would be any problem to use redux-toolkit together with redux-saga, because redux-saga is just a middleware, and the redux-toolkit (namely redux itself on which it is based) supports middleware - so they are perfectly compatible. As for my experience - I have never worked with redux-toolkit in prod (just trifled a bit myself - and I find it extra convenient), but I do work a lot with redux-saga.
It's very easy to use hooks-based query libraries. I find however, that this can lead to an async workflow controlled by the visibility and rendering of individual components. This is hard to follow and the rendering process isn't meant to be an event loop. Therefore I prefer to use RTK Query and thunks/sagas in Redux to specify the async workflow more clearly. RTK Query also supports hooks-based invocation.
I enjoy sagas and initially scoffed at my company's use of thunk. However, keeping your technology surface low and using react to drive the app makes for code that is easy to read. Even my most trivial dabbles with sagas have caused head spinning debug sessions.
@@AngusMcIntyre I can recommend typed-redux-sagas which uses yield * instead of yield to give you properly typed effects and in general. For most things I actually prefer thunks. Like simple fetching stuff. I use sagas for things like "autostart" to react to changing the route and stuff getting initialized. When the route changes I post an action "LOCATION" to the store, which enables all that. Storing of the location isn't even necessary but can be useful for selectors. Sagas are also good for being started in useEffect handlers. You can pass a ref to the saga and then for example use the ref to move elements into view when certain actions occur.
Sagas for the win. We (the team, but i managed it and did most) had to refactor a huge context based app to redux saga / immer as re-rendig was getting out of control and the app was getting out of sync. Callbacks via thunk just causes pain, redux and saga is the way, immer makes it easy!!! Tip - breakup as many slices as possible.
just switch honestly. I've been watching the React world for a few years now and I can't even understand why they bother with such poorly designed libraries. Svelte+SvelteKit has been pure bliss for me. All the problems I see people keep having just don't exist with the way svelte handles state and sveltekit handles page loads and app architecture
I do not agree with you here. The React query will fetch data before the component is mounted. You are getting "fetching products" before "component mounted" in your console because you wrote useQuery first in your component and then useEffect in your component. but both of them are actually running after components are mounted. You can check it by putting useEffect first and then the code of useQuery to check. Please correct me if i am wrong
The fact that the fetching/refetch is executed before useEffect is a very bad idea in many cases. For example I need to change the page and after that to send data with the new page as a parameter.
meanwhile me using vue, and calling my http requests in the "created" lifecycle hook (basically treating it like a class constructor), i just find react to be a lot more messier from a "where do i write my code" best practice standpoint
Nice little talk on React-Query v4 - there is not V5. I would say although yes a good quick overview and very basic comparison to redux. it would be good to speak a little slower and explain which packages say useQueryClient comes from as well as describe in more detail as to what is going on. but still good intro to this and worth running through.
what really is that difficult now, alrady is more efficient know config servers and cnds and pay google cloud than work with 3 libraries just for the fetch. really sometimes reiventing the wheel is funnier than be developer trend
Many thanks, nice comparison! @11:44, In order to use the cached query data, if my query keys has other params, ["queryName", param1, param2]. Do I need to include them in the useQuery hook, or just the "queryName" is enough? also the indiviual config option of that query?
I wonder why you don't have to make imports, for example for the "createSlice" method at 9:12 for example. Where does "createSlice" come from here? How does the file know that it exists?
If you think you should be able to read, understand and control the data flow in your own codebase instead of importing a 3rd party module: you're wrong
If you are ONLY using react query for data fetching you are doing it wrong. Managing packages in the JavaScript ecosystem is a nightmare. It's much more maintainable to write your own custom reusable hook if all your trying to do is fetch data.
Yeah this is pretty straightforward to write as well. Caching is hard but it isn’t so hard that it necessitates large 3rd party libraries for something as simple as data fetching.
I will prefer to use native api from react rather than installing other libraries just because of its easier. Who knows someday the new update will break your app.
For example if I have a list of items data and on another route /page I have to show my one data which having some specific data so how do i pass my params data to fetch function?
Awesome video. I have a question thought. Since in my company we use mostly the hash router and since it is proved to be incompatible with the new features of react-router 6.4 are you sure that I can use reacty-query library with the hash router?
I am newbie, can someone explain to me why he can simply call dispatch without using useDispatch and useAppState in react web but not react native project?
It's not wrong tho, you're using it the wrong way. I won't explain that you you or your viewers but you can go look for Dave Gray's videos if you want, he actually discuss about this in detail.
Abstractions like React Query, RTK Query, SWR, and similar are very nice and do make it easier to manage API logic when writing components. It should be really important to note though that these libraries are all implemented with useEffect. In fact, useEffect is the only way to fetch data on the client in functional react components! (Aside from handling user events, e.g. clicking a button)
Just some additional info for junior devs and newbies: while the video itself made sense under the context, we should all understand that the title is just for clickbait and it's incorrect strictly. useEffect() has some use cases other than api fetching if your projects involve some edge component like text editor, canvas, etc.. You will use it here and there at the end. However, there are people who are over-ignorant because they don't understand and don't want to understand the context behind those abstractions. If you saw people who simple state that hook is better than redux, react query is better than useEffect(), etc. you need be careful about their suggestions, because they probably don't understand React and DOM behavior at all.
Looks to me like the same amount of code and additional library, just for the sake of having an additional library. Why not just use fetch with Abort controllers and already defined hooks? Main problem with some new and cool technologies is the fact that you can't really use them for, let's say corporation clients. Vue, React and Angular (and frameworks based on them) are the main trio that will be here for years to come, while something like Svelte people love talking about is an unknown. it stands to reason that investing time in the aforementioned three is still the way to go
React Query is just what you suggested (but the JS ecosystem is like that, whenever they find some trend lib, they treat like its the new super cool shining thing that you need to be using for the sake of being cool) but bcoz its a lib, it supports other popular use cases that you might need when doing data fetching logic in client-side.
first of all, thanks that is better, But how can manuplate the products data like set liked product and render app, If I have a like button for each product, I could use set state to update the view in reactQuery I just get data, it is not a state var ? How to handle this situation ? Thanks
5:35 it not true always as useEffect is componentDidMount with empty dependency and which means when component is mounted and that means all the jsx rendering is already done than useEffect callback is fired where you are logging component mounted that is fine but you said first it fetch than render it is not true always with useEffect it first render than run callback in useEffect
I am really sincerely trying to see the usefulness of this tool. Don't get me wrong. I do understand that some teams might benefit from it, but the whole trying to make it sound as if it's THE WAY... it's just sounding like another shinning new discovery from JSboys, and it always doesn't last. I will pass for now. Thanks.
well, is just a very good implementation from a hook that does the same that the code that he presented in the start does, but following the performance best pratices that will be a pain is ass for you to do manually, like a lib should supposed to be.
So if i understand it correctly with React Query you are independent on API calls or can you like make it locally ? without any API calls ? idk if you want create cart and save data and update cart without any API/Backend, but with Redux Store f or example you can work only with Frontend and saving creating data and pushing them into the store and reuse them ? Sorry for my english its not good, and im new in React. Thanks for answering or understanding of my question
guys, what on earth is this?.... am i the only one that is sane enough to say this is a heap of rabble one way or the other? How on earth can a component be also responsible for accessing data? Is this what has happened from end devs trying to write some code? so much utter crap, just to do something so so so so simple.... the component and the data need to be separated and the data provided to the component via a DAL or DI NOT be responsible for getting, it like where on earth is ruse then?!?! Really wish all this nonsense is killed off, its just making SIMPLE things so soso difficult and its not just the tech its front ends without strong fundamentals trying to recreate the wheel that real devs have already done for decades.
It really seems like you understand this, but you should really stop moving your mouse and highlighting constantly. It is distracting that it is hard to follow along and read code. Your IDE keeps trying to show things, you have tons of movement and are going at a quick pace. Put all of that together and it really makes it hard for someone with attention issues (or other issues) to follow along. Again, kudos on knowing your subject. Presentation could use a little care IMHO. Thanks for listening.
that's code is bad, IMHO, cuz when u have a NORMAL api, NORMAL state manager (like mobx), u just forgot how to use this "useQuery" (FROM A ANOTHER LIBRARY (OMFG, thats so stupid, to have that small code from an another libs..)). Just use "reaction" in mobx, when u create a "store" -> then u can init this "api call" from anythere. also as mobx, u can use redux and etc.
Can't stand the newly added hooks. They are so difficult to debug and reason about. Especially the dependency array, omg, what a garbage, like why would you put a function there? The classes were so predictable, you always know where to look when the component is mounted/unmounted/updated. Now the logic is spread out into useEffect hooks.
what makes that video great, is, that you compare the "old" and "react query" way! I clearle can see and understand the advantages of react query now. thx!
your example can be improved even further if you create custom hooks on top of the useQuery hook, like, you could create a useProductsQuery hook and use it instead of the regular useQuery hook and have even less code repetition because of that
Just what I was thinking about! That's what one would do in a real world scenario IMO.
Can you give me a code example for that? I don't see a way that you can simplify it even more since we're getting data and isLoading and error from the useQuery hook.
@@TotallyNotZoid
This is how I would do it:
const useProductsQuery = (queryOptions) => {
const { data, isLoading, error } = useQuery(['key'], queryFunction, queryOptions);
return { data: products, isLoading: loadingProducts, error };
}
@@ikarosouza isn't it suppose to be like that?
const useProductsQuery = (queryOptions) => {
const { data, isLoading, error } = useQuery(['products'], queryFunction, queryOptions);
return { products: data, loadingProducts: isLoading, error };
}
I basically didn't get where you took "products" and "loadingProducts" as there were supposed to be a part of the returning object
Umm… kind of misleading. How do you think the query hook works? It uses useEffect. Why is everyone so afraid of a useEffect hook? Very confused…..
If you focus on the react query 3:53 part of the video (it says there is almost no difference between `useEffect` and `the query` when it comes to performance).
The main reasons are for easier, more readable and maintainable code and eliminating the need for a global store like Redux (at least for the server-side data).
Yes exactly! It's important for developers to understand that these libraries use useEffect. However, encapsulating your API logic in a hook that uses useEffect (which is what React Query does) is a good idea in my opinion.
Just write your own hooks yall
I will stick with my redux and Redux toolkit
one thing is to be consistent with your code and not switching things up and down.
Everyone! Follow me on Twitter and GitHub for more stuff:
🐦 twitter.com/ipenywis
🎖️github.com/ipenywis
As for me, one of the most convenient ways to separate logic of api calls and the following data processing is using redux-saga effects, and it's very good both in terms of code structuring and readability.
But for the newer ones with typescript they recommend redux-toolkit. Have you used that? It feels more messy with than redux-saga
@@StamyIIReturn I don't think there would be any problem to use redux-toolkit together with redux-saga, because redux-saga is just a middleware, and the redux-toolkit (namely redux itself on which it is based) supports middleware - so they are perfectly compatible.
As for my experience - I have never worked with redux-toolkit in prod (just trifled a bit myself - and I find it extra convenient), but I do work a lot with redux-saga.
yes absolutely true
It's very easy to use hooks-based query libraries. I find however, that this can lead to an async workflow controlled by the visibility and rendering of individual components. This is hard to follow and the rendering process isn't meant to be an event loop. Therefore I prefer to use RTK Query and thunks/sagas in Redux to specify the async workflow more clearly. RTK Query also supports hooks-based invocation.
Thank you .
Wc
I enjoy sagas and initially scoffed at my company's use of thunk. However, keeping your technology surface low and using react to drive the app makes for code that is easy to read. Even my most trivial dabbles with sagas have caused head spinning debug sessions.
@@AngusMcIntyre I can recommend typed-redux-sagas which uses yield * instead of yield to give you properly typed effects and in general. For most things I actually prefer thunks. Like simple fetching stuff. I use sagas for things like "autostart" to react to changing the route and stuff getting initialized. When the route changes I post an action "LOCATION" to the store, which enables all that. Storing of the location isn't even necessary but can be useful for selectors. Sagas are also good for being started in useEffect handlers. You can pass a ref to the saga and then for example use the ref to move elements into view when certain actions occur.
Sagas for the win. We (the team, but i managed it and did most) had to refactor a huge context based app to redux saga / immer as re-rendig was getting out of control and the app was getting out of sync. Callbacks via thunk just causes pain, redux and saga is the way, immer makes it easy!!! Tip - breakup as many slices as possible.
React-query or swr was the best thing to happen to React since hooks. Maybe the only reason why I haven't fully switched to svelte (yet)
just switch honestly. I've been watching the React world for a few years now and I can't even understand why they bother with such poorly designed libraries. Svelte+SvelteKit has been pure bliss for me. All the problems I see people keep having just don't exist with the way svelte handles state and sveltekit handles page loads and app architecture
@@sachahjkl I would, but I still have to support existing applications 🤷
New applications though... 😎
I like also the RTK Query
I knew react-query exists but never used it. After watching this video I think i am gonna use it my upcoming projects
Very nice description of how things work.
I do not agree with you here. The React query will fetch data before the component is mounted. You are getting "fetching products" before "component mounted" in your console because you wrote useQuery first in your component and then useEffect in your component. but both of them are actually running after components are mounted. You can check it by putting useEffect first and then the code of useQuery to check. Please correct me if i am wrong
Thank you!! .. 1st time hearing this library.. This help me a a lot.
The fact that the fetching/refetch is executed before useEffect is a very bad idea in many cases. For example I need to change the page and after that to send data with the new page as a parameter.
Title is wrong! Behing the scenes React Query uses useEffect() to fetch data😀
This absolutely helpful fetch and state mgt all in one. Would be great if you could also share how to unit test this. Thanks.
the damn thing uses useEffect under the hood. just open the repo and search for useEffect.
meanwhile me using vue, and calling my http requests in the "created" lifecycle hook (basically treating it like a class constructor), i just find react to be a lot more messier from a "where do i write my code" best practice standpoint
useEffect is the definition of what you just described...
imho this just overcomplicates api calls, I really don't feel react query is that flexible
Nice little talk on React-Query v4 - there is not V5. I would say although yes a good quick overview and very basic comparison to redux. it would be good to speak a little slower and explain which packages say useQueryClient comes from as well as describe in more detail as to what is going on. but still good intro to this and worth running through.
Your explanation is 💯💯💯
what really is that difficult now, alrady is more efficient know config servers and cnds and pay google cloud than work with 3 libraries just for the fetch. really sometimes reiventing the wheel is funnier than be developer trend
super neat, exactly what I needed
this is great explanation! 🎉
Many thanks, nice comparison!
@11:44, In order to use the cached query data, if my query keys has other params, ["queryName", param1, param2]. Do I need to include them in the useQuery hook, or just the "queryName" is enough? also the indiviual config option of that query?
big fan sir thank you for your efforts
Thanks!!
How do you change your VSCode activity bar icons look?
I wonder why you don't have to make imports, for example for the "createSlice" method at 9:12 for example. Where does "createSlice" come from here? How does the file know that it exists?
I like redux rtk query better , btw in React Router v6.4.2 there is new way to fetch data with loader function without using useEffect
what is the new way in react router?
If you think you should be able to read, understand and control the data flow in your own codebase instead of importing a 3rd party module: you're wrong
What's your theme and font btw?
hi bro please expalin the tanstack/reactQuery and how to use and benfits
If you are ONLY using react query for data fetching you are doing it wrong. Managing packages in the JavaScript ecosystem is a nightmare. It's much more maintainable to write your own custom reusable hook if all your trying to do is fetch data.
Yeah this is pretty straightforward to write as well. Caching is hard but it isn’t so hard that it necessitates large 3rd party libraries for something as simple as data fetching.
I will prefer to use native api from react rather than installing other libraries just because of its easier. Who knows someday the new update will break your app.
For example if I have a list of items data and on another route /page I have to show my one data which having some specific data so how do i pass my params data to fetch function?
♦️Can you do a full react query series?..♦️
Awesome video.
I have a question thought.
Since in my company we use mostly the hash router and since it is proved to be incompatible with the new features of react-router 6.4 are you sure that I can use reacty-query library with the hash router?
I'm tired of the "you're doing it wrong" type shii. Why not contribute to React official docs? So far your comments aren't Opinionated or Trend...
I am newbie, can someone explain to me why he can simply call dispatch without using useDispatch and useAppState in react web but not react native project?
New subscriber... loved your content
Cool stuff and thanks for showing us this. Is the code repo somewhere where we can access it?
It's in the description
github.com/ipenywis/react-query-useEffect
What extension do you use that shows the size of the packages right on the import statement?
That's awesome but how dependency array works with useQuery? What if I have to fetch again if some state change?
It's not wrong tho, you're using it the wrong way. I won't explain that you you or your viewers but you can go look for Dave Gray's videos if you want, he actually discuss about this in detail.
Can you do a tutorial on how to fetch data from an API using useQuery and pass it to a context provider?
Abstractions like React Query, RTK Query, SWR, and similar are very nice and do make it easier to manage API logic when writing components.
It should be really important to note though that these libraries are all implemented with useEffect. In fact, useEffect is the only way to fetch data on the client in functional react components! (Aside from handling user events, e.g. clicking a button)
Just some additional info for junior devs and newbies:
while the video itself made sense under the context, we should all understand that the title is just for clickbait and it's incorrect strictly.
useEffect() has some use cases other than api fetching if your projects involve some edge component like text editor, canvas, etc.. You will use it here and there at the end.
However, there are people who are over-ignorant because they don't understand and don't want to understand the context behind those abstractions. If you saw people who simple state that hook is better than redux, react query is better than useEffect(), etc. you need be careful about their suggestions, because they probably don't understand React and DOM behavior at all.
Looks to me like the same amount of code and additional library, just for the sake of having an additional library. Why not just use fetch with Abort controllers and already defined hooks? Main problem with some new and cool technologies is the fact that you can't really use them for, let's say corporation clients. Vue, React and Angular (and frameworks based on them) are the main trio that will be here for years to come, while something like Svelte people love talking about is an unknown. it stands to reason that investing time in the aforementioned three is still the way to go
React Query is just what you suggested (but the JS ecosystem is like that, whenever they find some trend lib, they treat like its the new super cool shining thing that you need to be using for the sake of being cool) but bcoz its a lib, it supports other popular use cases that you might need when doing data fetching logic in client-side.
Your video ends abruptly. Didn't you intend to do some outro?
he probably cut the video in the end but overall interesting video i must say
Had to cut it short 🙃
Have you ever heard about RTK Query? We can do the same with RTK Query even better.
I usually avoid installing more packages if I can do it with what I have
What vs code theme are you running?
I was about to ask the same question, it looks nice does it 😅
Just awesome bro thanks
Why using react query when we can write clean useEffect code?
How about using “SWR”?
Why do you need a separate "isLoading" state? Couldnt you just treat products===null as "isLoading===true"?
bcoz products === null can be an error state too, but it can be a derivated state from these two too.
Now I doubt whether using Zustand is correct.
doesnt useQuery use useEffect under the hood?
how could ReactQuery useQuery, useMutation wont conflict with ApolloClient useQuery, useMutation ?
rename it when you import
first of all, thanks that is better, But how can manuplate the products data like set liked product and render app, If I have a like button for each product, I could use set state to update the view
in reactQuery I just get data, it is not a state var ?
How to handle this situation ?
Thanks
you would use mutuate, and it would query once it's successful. It can also update optimistically.
@@none0n thanks 🙏, I figured it out the next day of that comment. Thanks I really appreciate your help . 🌹🌹🌹
How's the ide theme called?
Lol, you look like Kyle from Web Dev Simplified, both speaking and presenting.
i was trying really hard to remember what guy did he was reminding me of... thaaaanks!!!
Can you share your vscode settings? It looks like Halcyon but its different slightly. Also your file highlighting is nice! Please share
Did you find what is was?
@@KingKongHitDaBong inthink its halcyon with custom settings
What about parallel API calls? How we can use ReactQuery for parallel API Call?
use the "useQueries" hook
what's the vscode theme please
this is helpful thx keep it up
5:35 it not true always as useEffect is componentDidMount with empty dependency and which means when component is mounted and that means all the jsx rendering is already done than useEffect callback is fired where you are logging component mounted that is fine but you said first it fetch than render it is not true always with useEffect it first render than run callback in useEffect
Please review RTK Query
Anybody know what theme he's using?
idk man if it aint broke dont fix it. Use effect and fetch will always be husband and wife in my code
Is the code shareable, I love the design
I am really sincerely trying to see the usefulness of this tool. Don't get me wrong. I do understand that some teams might benefit from it, but the whole trying to make it sound as if it's THE WAY... it's just sounding like another shinning new discovery from JSboys, and it always doesn't last. I will pass for now. Thanks.
well, is just a very good implementation from a hook that does the same that the code that he presented in the start does, but following the performance best pratices that will be a pain is ass for you to do manually, like a lib should supposed to be.
and if the project does not use React Query for fetching data... use ...
Man, how do you test onFocus for text input on RN using RTL?
damn dude I had to use subtitles....Good content though!
Can you use React Query & Zustand similar to Redux & RTK query?
yes
@@MyPhuckDub You got a codesandbox link of an example of the integration of zustand store with react query you don't mind sharing?
Thank you.
I hate how refatch from useQuery dont actuly triger isLoading so you to need to hack it with useState
So if i understand it correctly with React Query you are independent on API calls or can you like make it locally ? without any API calls ? idk if you want create cart and save data and update cart without any API/Backend, but with Redux Store f or example you can work only with Frontend and saving creating data and pushing them into the store and reuse them ? Sorry for my english its not good, and im new in React. Thanks for answering or understanding of my question
What you just said it's not a production ready project, the project can only survive on your local machine.
Or, don't use either and use react async components.
Hate them
I hope this is a joke....
Thanks
guys, what on earth is this?.... am i the only one that is sane enough to say this is a heap of rabble one way or the other?
How on earth can a component be also responsible for accessing data?
Is this what has happened from end devs trying to write some code? so much utter crap, just to do something so so so so simple....
the component and the data need to be separated and the data provided to the component via a DAL or DI NOT be responsible for getting, it like where on earth is ruse then?!?!
Really wish all this nonsense is killed off, its just making SIMPLE things so soso difficult and its not just the tech its front ends without strong fundamentals trying to recreate the wheel that real devs have already done for decades.
thanks
Imagine importing a 3rd party library and claiming that it actually makes things load 1ms faster
It really seems like you understand this, but you should really stop moving your mouse and highlighting constantly. It is distracting that it is hard to follow along and read code. Your IDE keeps trying to show things, you have tons of movement and are going at a quick pace. Put all of that together and it really makes it hard for someone with attention issues (or other issues) to follow along.
Again, kudos on knowing your subject. Presentation could use a little care IMHO.
Thanks for listening.
I avoid useEffects for side effects.
useSWR more better
am I the only one disgusted by these new "use hook state effect" bs buzz words that zuckerberg is forcing into us ?
Can you scroll a bit more pls
umijs + dva solution much better :)
🥺 its beautiful
that's code is bad, IMHO, cuz when u have a NORMAL api, NORMAL state manager (like mobx), u just forgot how to use this "useQuery" (FROM A ANOTHER LIBRARY (OMFG, thats so stupid, to have that small code from an another libs..)). Just use "reaction" in mobx, when u create a "store" -> then u can init this "api call" from anythere. also as mobx, u can use redux and etc.
See the trick to this is ditching these frontend frameworks and using a fullstack framework like Laravel.
what an obvious video topic, of course you don't want to use that hook for API calls
Why
Can't stand the newly added hooks. They are so difficult to debug and reason about. Especially the dependency array, omg, what a garbage, like why would you put a function there? The classes were so predictable, you always know where to look when the component is mounted/unmounted/updated. Now the logic is spread out into useEffect hooks.
calm down, take it easy.
Using stuff like remix is for noobs
is easy, just use useLayoutEffect