Allow staleTime to be part of store (de)hydration

[jeroenpg]

Currently when dehydrating a query store, stale time is not part of the state so it's not included. So if there's a query with longer stale time than the default, it will actually refetch earlier than intended, depending on whether it was fetched on the server or not.

A solution could be adding serializeOptions and deserializeOptions in dehydrate/hydrate.

[TkDodo]

A solution could be adding serializeOptions and deserializeOptions in dehydrate/hydrate.

those already exist as options that can be passed to both dehydrate and hydrate. hydrate takes defaultOptions: { queries: ... } where you can pass which options should be applied to the query that gets hydrated.

[jeroenpg]

A solution could be adding serializeOptions and deserializeOptions in dehydrate/hydrate.

those already exist as options that can be passed to both dehydrate and hydrate. hydrate takes defaultOptions: { queries: ... } where you can pass which options should be applied to the query that gets hydrated.

staleTime is not part of it those options. I am not talking about default options for hydrating queries but about passing it as a hydration data on query level.

Here's an example:

// router.tsx
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      experimental_prefetchInRender: true,
      staleTime: 5000,
    }
  }
});

// someroute.tsx
export const Route = createFileRoute("/someroute")({
  loader: async (route) => {
    const meData = await route.context.queryClient.fetchQuery({
      // ... rest
      staleTime: 30 * 60000
    });

    console.log(meData);
  }
});

// on server
const queryCache = dehydrate(queryClient); // does not contain the stale time for a query

// on client 
hydrate(queryClient, queryCache); // no stale time was in hydration data, so they're all added with stale time = 5000

[TkDodo]

that’s because staleTime is not an option on a query, but on the observer. You can have multiple observers with different staleTimes for the same query.

a query only becomes stale (or fresh) the moment it is observed.

So if there's a query with longer stale time than the default, it will actually refetch earlier than intended

if you hydrate the query and have no instance of useQuery watching it, it is neither stale nor fresh. It’s inactive. Once an observer mounts, it will determine if data is stale or fresh. Not sure where it will “refetch earlier than intended” ?

[jeroenpg]

that’s because staleTime is not an option on a query, but on the observer. You can have multiple observers with different staleTimes for the same query.

a query only becomes stale (or fresh) the moment it is observed.

So if there's a query with longer stale time than the default, it will actually refetch earlier than intended

if you hydrate the query and have no instance of useQuery watching it, it is neither stale nor fresh. It’s inactive. Once an observer mounts, it will determine if data is stale or fresh. Not sure where it will “refetch earlier than intended” ?

I see although I don't understand why staleTime can be provided to queryClient.fetchQuery then since it's not an observer.

Basically want I wanted to achieve is have a fetch query in the loader that is only triggered max once per 5 minutes, whether on the client or not. What happens now is if the loader is triggered during SSR, the result is hydrated on the client with my defaultStaleTime (=5000 ms for me), and because of this the query is refetched after 5 seconds, instead of 5 minutes.

The behavior is different if the initial loader is triggered on the client.

[TkDodo]

I don't understand why staleTime can be provided to queryClient.fetchQuery then since it's not an observer.

it’s an extra option on fetchQuery to indicate that you only want to execute a fetch when data is older than the passed staleTime. In that sense, fetchQuery might not trigger the queryFn (ironic, I know) but it can just return cached data.

Basically want I wanted to achieve is have a fetch query in the loader that is only triggered max once per 5 minutes

That’s what staleTime of 5 minutes on fetchQuery should achieve ...

the result is hydrated on the client with my defaultStaleTime (=5000 ms for me)

again, staleTime doesn’t matter until data gets observed, so this shouldn’t matter.

and because of this the query is refetched after 5 seconds, instead of 5 minutes.

I don’t really follow why that should be the case. When you call fetchQuery with staleTime of 5 minutes, we:

• compute options by merging the defaults with what you pass:

query/packages/query-core/src/queryClient.ts

Line 440 in 747eea8

const defaultedOptions = this.defaultQueryOptions(options)

this step should yield staleTime: 5 minutes because what you pass in overrides defaults

• then we check if the query data is still fresh using that result:

query/packages/query-core/src/queryClient.ts

Lines 449 to 450 in 747eea8

	return query.isStaleByTime(
	resolveStaleTime(defaultedOptions.staleTime, query),

[jeroenpg]

You're right, it does actually respect the staleTime parameter. I think what threw me off is that in the DevTools it shows the default stale time if it's loaded via the server.

You can check my repo. Clicking on server side redirect to see the query is added with stale time 1000, via client side redirect it's 60000 but this discrepancy doesn't actually matter since it's not an observer

https://github.com/jeroenpg/solidjs-templates-9jhbqmys

[TkDodo]

I think what threw me off is that in the DevTools it shows the default stale time if it's loaded via the server.

yeah that’s because when we create a query, we pass all options from the consumer to it, and that might contain observer options. I guess a good fix would be to filter what we show in the devtools, as right now, it just shows everything, including excess properties.