What's the point of react query?
Answered
oxmaster posted this in #help-forum
oxmasterOP
such a question. And what's the point of using tools like userquery for client caching. For caching next requests.is js not enough? I would like to get a more detailed answer (this is if not counting all the convenient chips). Especially with the new next.js 14
Answered by fuma
Good resource, thanks to Risky User 
Next.js is server-side caching, it caches fetch requests/
However, Next.js cache has a limited way to revalidate - You can only revalidate cache on the server side. If you want to re-fetch data when user re-focus their window. It's impossible with built-in functionality of Next.js. In these cases, RQ is what you should use.
For instance, Discord uses client-side solutions so that it can update messages/channels in real-time. It doesn't make sense to waste server resources for getting the real-time functionality.
Next.js is server-side caching, it caches fetch requests/
unstable_cache on server to reduce unnecessary fetches. Hence client-side solutions like RQ can be replaced by Server Components when you are displaying static data like blog posts. However, Next.js cache has a limited way to revalidate - You can only revalidate cache on the server side. If you want to re-fetch data when user re-focus their window. It's impossible with built-in functionality of Next.js. In these cases, RQ is what you should use.
For instance, Discord uses client-side solutions so that it can update messages/channels in real-time. It doesn't make sense to waste server resources for getting the real-time functionality.
33 Replies
I think you should read: https://tkdodo.eu/blog/you-might-not-need-react-query (not all of your question is there, but it is useful imo)
oxmasterOP
thank
I just want so much to get away from all this client stuff. I understand that it will not be possible to get rid of it completely, but after watching the conference, where they seemed to show Suspense and did some kind of error catching and caching seems to be there, so the question arises why.
Good resource, thanks to Risky User
Next.js is server-side caching, it caches fetch requests/
However, Next.js cache has a limited way to revalidate - You can only revalidate cache on the server side. If you want to re-fetch data when user re-focus their window. It's impossible with built-in functionality of Next.js. In these cases, RQ is what you should use.
For instance, Discord uses client-side solutions so that it can update messages/channels in real-time. It doesn't make sense to waste server resources for getting the real-time functionality.
Next.js is server-side caching, it caches fetch requests/
unstable_cache on server to reduce unnecessary fetches. Hence client-side solutions like RQ can be replaced by Server Components when you are displaying static data like blog posts. However, Next.js cache has a limited way to revalidate - You can only revalidate cache on the server side. If you want to re-fetch data when user re-focus their window. It's impossible with built-in functionality of Next.js. In these cases, RQ is what you should use.
For instance, Discord uses client-side solutions so that it can update messages/channels in real-time. It doesn't make sense to waste server resources for getting the real-time functionality.
Answer
Next.js does have a client router cache, but it lacks options to customise.
TLDR; Use it for complex applications like dashboards
TLDR; Use it for complex applications like dashboards
oxmasterOP
Well, that is, the next cache is not suitable for sockets, etc
Next Cache only saves time to fetch or calculate something, it shouldn't be used like a magic
oxmasterOP
moments in which data is required in real time, and for one sample (one request) doesn't make sense, does it?
yeah
oxmasterOP
and unstable_cache is only needed to support other libraries in order to cache requests that are not based on the fetch API in the form of axios?
@fuma Good resource, thanks to Risky User <:AyameTeriDerp:920629244462239794>
Next.js is server-side caching, it caches fetch requests/`unstable_cache` on server to reduce unnecessary fetches. Hence client-side solutions like RQ can be replaced by Server Components when you are displaying static data like blog posts.
However, Next.js cache has a limited way to revalidate - You can only revalidate cache on the server side. If you want to re-fetch data when user re-focus their window. It's impossible with built-in functionality of Next.js. In these cases, RQ is what you should use.
For instance, Discord uses client-side solutions so that it can update messages/channels in real-time. It doesn't make sense to waste server resources for getting the real-time functionality.
If you want to re-fetch data when user re-focus their windowputs listener to that and runs the router refresh
@oxmaster and unstable_cache is only needed to support other libraries in order to cache requests that are not based on the fetch API in the form of axios?
Correct, also for libraries that can't customise fetch options
@riský > If you want to re-fetch data when user re-focus their window
*puts listener to that and runs the router refresh*
it doesn't work if it's not dynamic rendered, since data are fetched & cached server-side
oxmasterOP
Thank you all for the answers
wait, does it even make sense to cache the data that we receive in real time?
they change at the speed of light, don't they?
@oxmaster wait, does it even make sense to cache the data that we receive in real time?
If you want to pre-render them, it makes sense
The correct process will be [Server] -> [Client re-fetch the data after hydration] -> [on-demand update on client-side]
Where "server" can pre-fetch the data too, so that you don't have to add skeletons or spinners to your UI
oxmasterOP
In general, through initialData, yes? If we work with real-time?
Depends on you, at least for heavily real-time applications, they usually prefer client-side data fetching
and for a blog website? Server Components are enough
oxmasterOP
they usually prefer client-side data fetching... That is, it turns out that they usually do not even make a preliminary selection on the server, but just a request in the use Query?
Yeah, that's why you have a loading screen in Discord when launching the app
oxmasterOP
You just said that: [Client re-fetch the data after hydration] and "Where "server " can prefetch the data too" and it seemed to me that these are slightly different concepts, because if you make a request on the server and send it to initialData, then we generally lose such a thing as isLoading
@fuma Yeah, that's why you have a loading screen in Discord when launching the app
imagine SSR'd discord... that would be faster to load but overall worse
oxmasterOP
you just said that they do pre-sampling on the client, and then on the server, but there is no isLoading on the server, and there is a client, but you said that there is a loader. That's why I got a little confused
loading.tsx for nextjs maybe
@oxmaster You just said that: [Client re-fetch the data after hydration] and "Where "server " can prefetch the data too" and it seemed to me that these are slightly different concepts, because if you make a request on the server and send it to initialData, then we generally lose such a thing as isLoading
They may not prefetch data on server, since it can take a lot of server resources
oxmasterOP
Understood, in general it depends on the situation. If it is too hard to make a selection and will take a lot of time, then it is better on the client
Usually depends on how you want to revalidate them, - yes
oxmasterOP
ok, thanks again for the answer