Make dehydrate async + wait for active queries to finish?

[patrick-mcdougle]

Dehydrate synchronously dehydrates all successful queries and ignores queries that might be in flight (fetching), but what if it was async and had an option to wait for all active queries to finish before finally dehydrating? Would this be a feature that would be desirable? I know I'd like it, but would anyone else want / need this?

[TkDodo]

Can you elaborate on what use-case you have / problem you're trying to solve?

[patrick-mcdougle]

In our app we use react query on both the server + on the client. We have some queries that are server only, some queries that are client only and some "shared" queries that are run on the server and on the client. We like the unified interface for data fetching (always communicating through a queryClient either through fetchQuery or through the hooks). Queries that are server only do not have to have their implementations placed on the client at all because the server queries are converted into static props. Here is a very stripped down pseudo code example.

We're using Next.JS for our app.

// Next JS Page file

export const getStaticProps = composeProps(async (queryClient) => {
    // Notice how we're not awaiting this one...
    queryClient.fetchQuery('someSharedKey');

    const serverData = await queryClient.fetchQuery('someServerKey');

    return {
        props: {
            serverData,
        },
    };
});

export function Page({serverData}) {
    const { data: sharedData } = useQuery('someSharedKey');
    const { data: clientData } = useQuery('someClientKey');

    return <h1>{serverData + sharedData + clientData}</h1>;
}

// composeProps
export function composeProps(asyncCallbackTakingAQueryClient) {
    const queryClient = new QueryClient();

    // this query "registration" happens in another file, but this is the gist...
    queryClient.setQueryDefaults('someServerKey', { queryFn: aQueryFunctionImplementationFromSomewhere });
    queryClient.setQueryDefaults('someSharedKey', {queryFn: aQueryFunctionImplementationFromSomewhereElse });

    const someProps = await asyncCallbackTakingAQueryClient(queryClient);
    
    // This is the special sauce...
    // without awaiting the active queries, someSharedKey might still be fetching and will not be dehydrated.
    // we also control which queries are dehydrated here using query meta to control an opt-in to dehydration which I've omitted here.
    // in this example, dehydratedState would be contain only the dehydrated query for someSharedKey, since we used the someServerKey query only as static props for NextJS to serialize into the props json file at build time.
    const dehydratedState = await dehydrate(queryClient);

    return (nextContext) => {
        props: {
            ...someProps,
            dehydratedState,
        }
    };
}

// _app

function App({ pageProps, Component }) {
    const browserQueryClient = new QueryClient();
    // again, this happens in another file, but this is the gist of how we register the queries that are either client or shared.
    queryClient.setQueryDefaults('someClientKey', { queryFn: aQueryFunctionImplementationFromSomewhere });
    queryClient.setQueryDefaults('someSharedKey', {queryFn: aQueryFunctionImplementationFromSomewhereElse });

    return (
        <QueryClientProvider client={queryClient}>
            <Hydrate state={pageProps.dehydratedState}>
                <Component {...pageProps} />
            </Hydrate>
        </QueryClientProvider>
    );
}

Without an async hydrate, depending on how fast the implementation of someSharedKey is, it might or might not have completed it's fetching by the time we call dehydrate on it. If it's faster than someServerKey, it will be dehydrated. If it's slower than someServerKey it might not be.

I understand that this is an unconventional use case (and I think we can work around it by polling on if there are active queries) but I personally think this would be useful (and could be opt-in / BC compatible as a new option to dehydrate).

Whew, that was a lot. Please let me know if something isn't clear.

[TkDodo]

okay but why don't you just await the query?

// Notice how we're not awaiting this one...
queryClient.fetchQuery('someSharedKey');

side note: unless throwing errors is okay, you'd likely want prefetchQuery over fetchQuery.

[patrick-mcdougle]

Perhaps this isnt a compelling reason, but there's work between here and dehydrate in my code that doesn't need to be blocked by this query.

[TkDodo]

right. in this case, I think what you'd need to do is manually wait until fetching has finished. something that useIsFetching is doing initially, meaning:

const queryCache = queryClient.getQueryCache()
const hasFinishedFetching = new Promise((resolve) => {
    const unsubscribe = queryCache.subscribe(() => {
      if (queryCache.isFetching() === 0) {
        unsubscribe()
        resolve()
      }
    })
}

await hasFinishedFetching

[patrick-mcdougle]

Thanks for the suggestion! Now can it be an option to dehydrate() instead of in my code? 🤣

Feel free to mark this as resolved.