New refetchOnMount option

[chekrd]

This one can be linked to a question #4099.

AFAIK there is no way to suspend the component while refetching already cached (no matter the stale status) data on mount.

Is it possible to extend refetchOnMount option with something like 'alwaysForceLoading'? So even when the data are in the cache, refetchOnMount will behave like the first mount, loading will be true and suspense would be triggered.

[TkDodo]

we've had this discussion before, and even a PR:

• feat: determine whehter suspend by user #3935

conceptually, I don't think it makes much sense to suspend on background refetches, as this would mean you do not want to utilise stale-while-revalidate, the principle react-query is built upon: show stale data while you're refetching in the background, then update the screen with new data.

I'm not sure what the use-case for this would be, but for example, for imperatively triggered refetches, you can use queryClient.resetQueries, because that will reset data in the cache to the initial value and then re-render observers. So if the initialValue is undefined, the re-render will trigger a new fetch and it will thus suspend.

[chekrd]

It does make sense to me sometimes suspend on mount-refetch as no matter how you trust your query staletime in the rest of the app, if the component is an editor of the entity, a user wants to start editing the last version of the entity. I assume this is what most projects want. Without suspense, the user can drop connection speed so mount-refetch & rerender can happen after the user makes a change on an old entity state, overwriting the state the user never saw. The easiest thing we can do is to suspend the editor until the refetch is done. Better loader in this part of the app than letting users mess with data.

We want to avoid doing imperative fetch on mount as it means to do something like this (btw this is very similar to our current implementation). No suspense here, though :(

const forceFetchMyEntityForEditing = (queryClient, entityId) => {
  const fetchQuery = () => queryClient.fetchQuery({
    staletime: 0,
    queryFn: ...,
    queryKey: ...,
  });

  return makeCancellablePromise(fetchQuery);
};

const MyEntityEditor = ({ entityId }) => {
  const [editedEntity, setEditedEntity] = useState(null);
  const queryClient = useQueryClient();

  useEffect(() => {
    const fetchPromise = forceFetchMyEntityForEditing(queryClient, entityId)
      .then(setEditedEntity)
      .catch(swallowCancelledPromiseError);
  
    return () => fetchPromise.cancel();
  }, [queryClient, entityId]); // Never refetch the entity. The user is warned about concurrent updates through a notification service.

  return editedEntity ? <Editor state={editedEntity} /> : <Spinner />; // If higher in the tree is another suspense spinner, the spinner blink happens as this spinner is rendered after the suspend.
};

// All other components in the app fetching MyEntity for reading purposes are using useQuery.

And we want to use RQ for not doing this boilerplate.

With proposal refetchOnMount: 'alwaysWithSuspense' (ignore the name) implemented, suspense is working:

const MyEntityEditor = ({ entityId }) => {
  const [editedEntity, setEditedEntity] = useState(null);
  const { data } = useFetchMyEntity(entityId, { refetchOnMount: 'alwaysWithSuspense', suspense: true }); // useQuery inside

  // Once fetching/suspense is done, effect is called. Future data updates through RQ cache are ignored.
  useEffect(() => {
      setEditedEntity(prevState => (data && data.id !== prevState?.id) ? data : prevState);
  }, [data, entityId]);

  // The first render after the suspense is null, then Editor. Editor itself subscribes to a concurrent updates notification service.
  return editedEntity ? <Editor state={editedEntity} /> : null;
};

Reseting the query before fetching will end up in suspense-refetch-reset-suspense loop. The solution can be moving the reset above the <Suspense />, but this is a nogo in a large app as it can be far away from the fetching component. Because our products are large, we want to use Suspense so we don't have to think about code relations in the tree.

My last idea for a workaround was using something like this https://github.com/vigzmv/react-promise-suspense (for wrapping the client.fetchQuery) but it didn't seems right.

I didn't find the Twitter post that you mentioned here.

[TkDodo]

if the component is an editor of the entity, a user wants to start editing the last version of the entity. I assume this is what most projects want. Without suspense, the user can drop connection speed so mount-refetch & rerender can happen after the user makes a change on an old entity state, overwriting the state the user never saw. The easiest thing we can do is to suspend the editor until the refetch is done. Better loader in this part of the app than letting users mess with data.

You are talking about forms where you likely don't want background refetches because of exactly the reasons you mentioned - they would overwrite user input. There are different techniques to solve this, which I have outlined here: https://tkdodo.eu/blog/react-query-and-forms

But it has nothing to do with wanting to suspend even if you have cached data imo..

I didn't find the Twitter post that you mentioned

https://twitter.com/acemarke/status/1557896884286590976

[chekrd]

But it has nothing to do with wanting to suspend even if you have cached data imo..

You are right. There is no solution for this except forking the RQ, building everything from the ground, or adding the feature to RQ hook.
RQ internals seems to be prepared for this, and it should be easy to introduce the feature. I can imagine something like useQuery option "reuseStaleDataOnMount": boolean (or QueryState => boolean), so the query with options { reuseStaleDataOnMount: false, staleTime: 0 } can be fetched in a UI blocking way no matter the suspense option.

I hate use-case specific options (because of testing and maintaining). That's why I like #3935. Your comment is not a workaround as we cannot use it during a query mount (resetting in useEffect is too late, doing side effects during a render is wrong, and resetting the query in render phase will cause an infinite loop). So not sure why it was closed.

I like to see React team working on the promise hook, but it can take years to release if ever. Then, of course, we could be able to use queryClient.fetchQuery with it.

I would say we need your opinion or reason why not to support this. We can try to create a PR then.

[TkDodo]

So not sure why it was closed.

It was closed because initializing suspense might become a hook call so we might not be able to do "conditional suspense", or we might have to revert it later if react goes that way.

Btw, we already support the isFetchedAfterMount boolean as part of the response, I think this would be what you want?

- `isFetchedAfterMount: boolean`
  - Will be `true` if the query has been fetched after the component mounted.
  - This property can be used to not show any previously cached data.