useQuery together with prefetch on Next.js SSR

[italodeandra]

Hi team,

Currently I'm using react-query on a Next.js project, where I prefetch the query on its SSR (getServerSideProps).

If I load the application and navigate to a page where you have the prefetch on the server side and a useQuery on the client side. You will end up with two requests fetching the exact same data, one from Next.js and another from react-query.

My question is, should I be handling this behavior differently or is this double request is desirable? To me it seems redundant and I actually don't know exactly the best approach to take.

[TkDodo]

are you prefetching the query with queryClient.prefetchQuery and then use hydration? If so, I think you are just experiencing what's described here:

https://react-query.tanstack.com/guides/ssr#staleness-is-measured-from-when-the-query-was-fetched-on-the-server

Because staleTime defaults to 0, queries will be refetched in the background on page load by default. You might want to use a higher staleTime to avoid this double fetching, especially if you don't cache your markup.

[italodeandra]

are you prefetching the query with queryClient.prefetchQuery and then use hydration?

Yes

If so, I think you are just experiencing what's described here:

Yeah, but in this case it suggests that my data would not update that often which is not the case. I don't want to increase the staleTime if it means that I will get outdated data. Should I still use it?

The main reason I use react-query is because it will refetch when the component is mounted, when the window is focused and when the network goes back. Only this "double request" that bothers me. (it isn't actually double request, because one is from Next.js SSR and the other is the actual useQuery, but they return the same thing).

[TkDodo]

well theoretically, your nextJs page could do SSG, in which case you might have old cached data, which you would still serve and then revalidate on the frontend, so I think the mechanism is what we want.

Yeah, but in this case it suggests that my data would not update that often which is not the case. I don't want to increase the staleTime if it means that I will get outdated data. Should I still use it?

setting staleTime is exactly what you want here, maybe to something as low as 20 seconds. StaleTime just means:

Dear react-query, if you already have data in the cache that is not older than 20 seconds, please give it to me without making another request. If it's older, give it to me anyway, but make a revalidation request.

This will be true for all sorts of refetches (mount, windowfocus, reconnect). The default of 0 just makes sure that every one of these events will yield a new fetch. But apparently, this is not what you want, because you get a refetchIOnMount when the component hydrates on the frontend.

If you want to keep staleTime to zero because your data updates so frequently - then you might also want it for this scenario because the data could already be outdated after the hydrated content has been sent to the frontend.

relevant read: https://tkdodo.eu/blog/react-query-as-a-state-manager

[italodeandra]

Nice, thanks. That's crystal clear.