prefilling other queryClient data inside queryFn

[schmitch]

Hello I want to ask if something like that is fine todo:

    const {isFetching, data} = useQuery({
        enabled: !!efinGuid,
        queryKey: ['documentSide', efinGuid],
        staleTime: 0, // stale time is always 0
        gcTime: 0,
        refetchOnWindowFocus: false,
        queryFn: async ({signal, client}) => {
            const data = await DocumentSideService.getDocumentData(efinGuid!, signal);

            const {settingsInvoiceContent, ...documentSideStoreData} = data;
            const newStore = documentSideStore({
                ...documentSideStoreData,
                loaded: true,
                storeLocation: StoreLocation.DocumentSide,
                selected: documentSideStoreData.view.document.emptyContainer ? null : documentSideStoreData.view.files[0],
            });

            // this prefills our query cache, so that we do not need to refetch the query, which is really cool
            client.setQueryData(
                invoiceSettingsQueryKeys.detail(documentSideStoreData.view.document.id),
                settingsInvoiceContent,
                {
                    updatedAt: new Date().valueOf(),
                },
            );
            
            return newStore;
        },
    });

i.e. the client.setQueryData.

[sueun-dev]

Yes, this is totally fine — it's a recognized pattern called the "push approach" to cache seeding, and TkDodo wrote a whole post about it: Seeding the Query Cache. The TanStack docs also cover it in the Prefetching guide.

The idea is exactly what you're doing: a single API call returns data for multiple queries, so you write the related data into the cache proactively instead of making extra network requests later.

A few things worth knowing with your specific setup:

gcTime: 0 on the main query doesn't affect the seeded entry

The gcTime you set on the documentSide query only applies to that query. The settingsInvoiceContent entry you write via client.setQueryData() will pick up whatever gcTime is configured for that key (or the global default of 5 minutes). So the seeded data should survive long enough for the user to navigate to where it's used.

The exception: if you have gcTime: 0 set globally in your QueryClient defaults, seeded entries become inactive immediately after write and get garbage collected almost instantly — before anyone can use them. If that's your setup, you'd want to pin a longer gcTime for the invoice settings key:

queryClient.setQueryDefaults(invoiceSettingsQueryKeys.detail(id), {
  gcTime: 5 * 60 * 1000, // 5 minutes
});

staleTime: 0 means the seeded data will trigger a background refetch when consumed

When a component mounts with useQuery(invoiceSettingsQueryKeys.detail(...)) and staleTime is 0 (the default), it'll immediately consider the seeded data stale and fire a background refetch. The component still renders with the seeded data instantly — so there's no loading state — but a network request goes out. If you want to suppress that refetch, set a positive staleTime for the invoice settings query:

queryClient.setQueryDefaults(invoiceSettingsQueryKeys.detail(id), {
  staleTime: 60 * 1000,
});

One thing to check: data structure completeness

This only works cleanly if the settingsInvoiceContent shape returned by the document endpoint matches exactly what the invoice settings detail query expects. If the detail endpoint returns extra fields, the seeded version will be incomplete and the user might see a flash of incomplete data before the background refetch fills in the gaps. Usually fine, just worth checking.

Overall, the pattern is solid. The updatedAt you're passing to setQueryData is a nice touch — it lets initialDataUpdatedAt consumers know when the data was last fresh.