No way to get cacheTime working when preloading queries via SSR

[kostia1st]

Describe the bug

cacheTime customizations get completely neglected once you provide query data on the server via the rehydration mechanics. The data itself is present no worries, but cacheTime is ignored (and probably other options, but I never checked)

Your minimal, reproducible example

no way I could provide one with SSR set up

Steps to reproduce

1. In the client code (in a component), make sure you customize the cacheTime: 1230000 when using useQuery:

useQuery(['yo'], () => Promise.resolve([123]), { cacheTime: 1230000 });

2. In the server code, set the query data with cacheTime provided via queryClient.prefetchQuery:

queryClient.prefetchQuery(['yo'], () => 'data', { cacheTime: 2340000 }),

3. Run the application with DevTools enabled, and check the ['yo'] query in the Query Explorer:

cacheTime: 300000

Note, the actual value is not 1230000 and not 2340000, but the default 300000 which means that react-query ignored all the customizations provided via both server and client code.

This will NOT happen if you remove the SSR code from your app. cacheTime gets set properly when the data entry originates from direct browser-to-API request.

Expected behavior

Logically I'd expect the cacheTime set by prefetchQuery to take precedence over any other values.

Then, in order of precedence, should go the value set at the component level.

If none of the above provided, the default one should get used instead (300 seconds).

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• OS: Windows 11
• Browser: any
• Node.js: 16.13.1

react-query version

3.34.8

TypeScript version

4.5.4

Additional context

No response

[TkDodo]

no way I could provide one with SSR set up

we have a next-js ssr example in the docs?

to answer the question: we only dehydrate the state of the query, not it's options:

https://github.com/tannerlinsley/react-query/blob/19861272f57da5e587bce5bff449d0c3020243e0/src/core/hydration.ts#L60-L66

what I would do is to set the defaults in the QueryClient, or via setQueryDefaults, or directly on the useQuery on the client rather than on the server.

[kostia1st]

Thanks for answering. I went with setting global defaults, but don't find it a logical or intuitive solution. Also, it puts some avoidable limitations, and causes inconveniences.

I still think that query metadata (cacheTime, staleTime and alike) is an essential part of the query data and should not be neglected in the de/rehydration cycle.

[TkDodo]

the problem is that you might want to set a different cacheTime on the server than on the client. For staleTime, we have the problem that it is an observer level property, not a cache-level one, so I don't think we could dehydrate it as prefetching doesn't create an observer and you also might not have an observer on the client.

[sneakyfildy]

setQueryDefaults is not convenient to use, it has to be applied before hydration. Imagine a SPA application with one QueryProvider wrapping it. When we initialise things on a client, we do not know which page we will work with and we do not know SSR Query contents, but we know that for certain page there may be a specific type of content which has to have Infinite cacheTime, this is super-clunky to use.
Probably having an ability to alter existing queries (already in cache) settings could solve that so that you can apply same settings on client for a specific query but in any moment of time.