Synchronize UI updates of multiple useQueries

[johanobergman]

Is it possible to synchronize the UI updates of multiple useQuery calls (with different keys)?

Let's say I have 5 different useQuery calls in different parts of the UI. If the fetches all take between 100 - 300 ms to complete, I assume I'll end up with the UI updating 5 times within 200 ms - a somewhat jarring user experience.

The same can be said when using invalidateQueries after a mutation - if I invalidate multiple queries at once, the UI will update a lot in a short amount of time.

Is there a way to tell React Query to batch UI updates that happen in quick succession? I guess the useQuery part could be solved with Suspense, but with invalidateQueries I don't want revalidating queries to suspend - I want them to show the old data until all of them are refetched (within a given threshold perhaps).

[TkDodo]

That sounds like an interesting problem, I'll have to think a bit about that one.

[TkDodo]

So, I think for initial loading, the idea is quite easily to check the loading states of all queries, possibly with useIsFetching if you don't have them all available at the top location. You can display a loading spinner until all data is here.

For background updates, like after query invalidation, it's a bit more tricky. First of all, it wouldn't be as "jarring" because your 5 queries already have data, so there would only be a layout shift of all of them would return different data. If that is "expected" or likely to happen, you can just fallback to showing a big loading spinner instead (see above).

if you really want to basically "keep previous data" until all 5 queries have finished fetching, and then update the ui once with all the new data, I think you would have to roll it manually, something like:

• copy the data to local state (with a useEffect)
• do the isFetching check
• while any of your 5 queries is fetching, return the local copy of the previous state
• update the local copy after all queries have finished

that could be abstracted away in a custom hook, but I think it's a niche use-case

[johanobergman]

I agree on the initial loading case - that seems like a good solution.

I'm not so sure the background update sync is a niche use case. A simpler use case - the user changes his username in a settings page. The username is loaded both in a query in the settings page and in a different query in the navbar. The usernames will currently always update out of sync (unless the api response times are identical). Since query invalidation is a big thing in this library, it feels like it could happen quite often. Your solution seems like an okay way to do it, although it might be a bit brittle given that every query needs to know what other queries they should wait for.

Maybe a batched updates api like this could be something?

client.batch(() => {
  client.invalidateQueries(...)
  client.invalidateQueries(...)
})

On a related note - is there a way to invalidate on fetch?

Let's say I have a list of blog posts, and a detail view of the selected post, using two separate queries. If I select a post (and its title has been updated server side since last fetch), the detail view and list view shows different post titles. Although refetching after the detail view has loaded will still cause an unsynchronized update - they'd have to be fetched in parallell and batched (at this point it seems like we're headed towards refetching all queries on every interaction, losing all benefits of caching).

Is seems like wherever I look small data inconsistency issues pop up - but maybe I'm looking too hard. I realize there has to be tradeoffs in order to keep the api simple. A lot of these issues could be solved using a normalized cache but I understand the decision not to use one.

[TkDodo]

Maybe a batched updates api like this could be something?

well I think it's the nature of async requests that they happen asynchronously. If you know what is going to change and want that, like in your username example, you could optimistically update and batch it with notifyManager.batch (only work for synchronous updates).
If you were to batch async updates, what happens if one request fails and retries are happening? It could take many seconds until you get an error, so you would delay all other requests a lot unnecessarily ...
Another way, if you really want that, is to just make one query to rule them all:

useQuery('all', () => Promise.all([axios.get('one'), axios.get('two)])

and then maybe use select to subscribe to parts of it.

---

On a related note - is there a way to invalidate on fetch?

I've never had that problem, but if you want that and overfetching isn't an issue, you can make your detail view use the list query and subscribe to the part where the id matches. Otherwise, the only way would be to refetch the list query manually when the detail query gets data or so ... but yeah, you would get into refetch everything all the time pretty fast

[johanobergman]

You could possibly batch within a specific time interval instead of waiting for every single request.

And thanks for your thoughts, it's been insightful.

[matthieugicquel]

Here's another use-case where this batching could be useful:

const Component = () => {
  const { data: todoItem } = useQuery(/* ... */);

  // The component used to display our entity depends on its status
  if (todoItem.status === "todo") {
    return <EditTodoForm item={todoItem} />;
  }

  /* ... */
};

const useSaveTodo = () => {
  return useMutation({
    /* ... */
    onSuccess: async () => {
      // Invalidate both the list query and the details query
      await Promise.all([
        queryClient.invalidateQueries({ queryKey: "todos" }),
        queryClient.invalidateQueries({ queryKey: `todo/${todoItem.id}` }),
      ]);
    },
  });

const EditTodoForm = ({ todoItem }) => {
  const { mutate, isPending } = useSaveTodo();

  // The requirements here are: save the change, show a loader in the button while ensuring all data is up-to-date, and the go back to the "list view" which should already be up-to-date

  const onConfirm = () => {
    mutate(/* ... */, {
      onSuccess: navigation.goBack
    });
  }

  return (
    <>
      {/* ... */}
      <Button onPress={mutate} isLoading={isPending}></Button>
    </>
  );
};

When running the mutation, if it results in todoItem.status changing:

• without batching, the UI may "jump" to the UI for the new status before navigation.goBack is executed
• with batching, it's not an issue

Here's the userland implementation we're currently using to "batch-commit invalidation results"

import {
  type FetchQueryOptions,
  type QueryKey,
  skipToken,
} from "@tanstack/react-query";

import { queryClient } from "#shared/query-client/queryClient";

/**
 * Invalidate multiple queries and wait for all of them to be fetched before saving to the query cache and triggering React re-renders
 */
export const batchInvalidate = async <TQueryKey extends QueryKey>(
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  queryOptions: FetchQueryOptions<any, Error, any, TQueryKey>[],
) => {
  for (const options of queryOptions) {
    // Mark queries as invalidated, but don't refetch them yet
    await queryClient.invalidateQueries({
      queryKey: options.queryKey,
      refetchType: "none",
    });
  }

  const queriesToRefetch = queryOptions
    .map((options) => {
      // Select all relevant active queries, including the ones specified with partial keys
      return queryClient.getQueryCache().findAll({
        queryKey: options.queryKey,
        type: "active",
      });
    })
    .flat();

  let pendingCount = queriesToRefetch.length;

  let markAllInvalidationsDone: () => void;

  const allInvalidationsDonePromise = new Promise<void>((resolve) => {
    markAllInvalidationsDone = resolve;
  });

  const markOneReady = () => {
    pendingCount -= 1;

    if (pendingCount === 0) {
      markAllInvalidationsDone();
    }
  };

  await Promise.allSettled(
    queriesToRefetch.map((query) => {
      const { queryKey, queryFn, ...options } = query.options;

      if (!Array.isArray(queryKey) || !queryFn || queryFn === skipToken) {
        markOneReady();

        return Promise.resolve();
      }

      return queryClient.fetchQuery({
        ...options,
        // eslint-disable-next-line @tanstack/query/exhaustive-deps
        queryKey,
        queryFn: async (context) => {
          let result;

          try {
            result = await queryFn(context);
          } finally {
            markOneReady();
          }

          // Wait for all invalidations in the batch to be done
          await allInvalidationsDonePromise;

          // Commit to query cache, this will trigger React re-renders
          return result;
        },
      });
    }),
  );
};