Realtime data and stale time

[Ehesp]

Hey,

I'm building a library for Firebase (react-query-firebase) & there's a logic flow I'm not sure how to handle.

When working with Cloud Firestore, we can subscribe to realtime updates. In basic form, you can do something like this:

  const ref = doc(firestore, 'products', id);
  const product = useFirestoreDocument(["products", id], ref, { subscribe: true });

Behind the scenes, a subscription is created using the Firebase SDK (code).

Now, since the data is updating the query cache manually anytime data is updated, I am setting staleTime to Infinity. This ensures that any new hooks using the same query key don't create a new realtime subscription (since there is no point). This works fine.

The issue is when a cacheTime exists (which it does by default). If all usages of a hook are no longer in use, I unsubcribe from Firestore realtime updates.

If the hook is reused again whilst the data is still in the cache, the "queryFn" never fires again, meaning no more updates.

Question

How can I go about saying "this data while in use is never stale, however if a query key is used and cached data exists, I want to trigger the 'queryFn' again".

[TkDodo]

Question
How can I go about saying "this data while in use is never stale, however if a query key is used and cached data exists, I want to trigger the 'queryFn' again".

I think you would have to set cacheTime to 0 to remove the query from the cache as soon as the last observer unsubscribes. This means you'll loose the cached data instantly, but the queryFn will be invoked then.

Otherwise, maybe you can keep the staleTime to 0, but disable the query once the queryFn has fetched? The realtime updates would still update the cache, but no other fetches would take place.

[TkDodo]

I think what you can also do is refetchOnMount: 'always', because per default, only stale queries refetch on mount. But this will be true for all usages of your query, not only when it has no observers.

[Ehesp]

Awesome that seems to be doing the job from local testing. Thanks a lot!

[Ehesp]

Ok so although that works in refetching the data/subscribing a user in the issue linked pointed out it will create new subscriptions when additional mounts happen - which in Firestore is bad as it creates additional reads.

The only way I can see this working, is by keeping staleTime: Infinity, refetchOnMount: 'always' and then somehow keeping track of which query keys (using the hashFn) have an active subscription, something like:

1. hook mounts, no listeners exist for query key, perform queryFn & increment listener count.
2. Another hook mounts, theres already a subscription for the query key, return data from via getQueryData & increment listener count.
3. If all hooks unmount (listener count 0), remove the subscription.

Something like this:

const subscriptions = {};
const listeners = {};

export function useFirestoreDocumentData(queryKey, ...) {
  // ..

  const hash = hashQueryKey(queryKey);

  useEffect(() => {
    return () => {
       listeners[hash]--;
       if (listeners[hash] === 0) {
         // unsubscribe
         subscriptions[hash]();
         subscriptions[hash] = null;
      }
    }
  }, [hash])



  return useQuery({
    queryKey,
    staleTime: Infinity,
    refetchOnMount: 'always',
    async queryFn() {
      // Someone is already listening
      if (listeners[hash]) {
        listeners[hash]++;
        return queryClient.getQueryData(queryKey);
      }

      listeners[hash] = 1;

      return new Promise(() => {
         // ... same logic as current
        subscriptions[hash] = onSubscribe(....);
     });
    },
  });
}

This is probably terrible code but hopefully illustrates the idea & issue. I'm not sure what happens here if multiple hooks mount/unmount at the same time - working with global variables seems like it could cause issues?

[TkDodo]

I don't fully understand the issue. If calling the query function multiple times is an issue, I don't think its a good idea to couple subscriptions to query functions. I think they are two different things:

• the query function can execute an fill the cache with data
• the subscription can run separately in an effect, and you likely only want one on app level.

I have some examples here: https://tkdodo.eu/blog/using-web-sockets-with-react-query and I'm also linking to this article, which shows a firebase example: https://aggelosarvanitakis.medium.com/a-real-time-hook-with-firebase-react-query-f7eb537d5145

[Ehesp]

Thanks - the issue is essentially there can be many subscriptions for different queries, however it only ever makes sense to have a single one per query key at a time.

I think I need to revisit how the realtime aspect is working, something like this comment