Dropping useQuery in favor of ensureQueryData + revalidateIfStale in loaders

[SebKranz]

I’ve recently been wondering if it could make sense to use the queryClient without any hooks at all, and instead configure the router to revalidate whenever there's any new data in the query-cache:

function useRevalidateOnQueryClientChange() {
  const revalidator = useRevalidator()
  const queryClient = useQueryClient()
  useEffect(() => {
    const unsubscribe = queryCache.subscribe((event) => {
      if (
        event.type === "updated" &&
        (event.action.type === "error" ||
          event.action.type === "success" ||
          event.action.type === "setState")
      )
        revalidator.revalidate() // maybe do some debouncing here...

    return () => unsubscribe()
  }, [revalidator, queryClient])
}

function clientLoader() {
  return queryClient.ensureQueryData({
    ...query(),
    revalidateIfStale: true
  })
}

function Route() {
  const data = useLoaderData()
  useRevalidateOnQueryClientChange()
  ...
}

The motivation for this is to simplify working with complex dependent queries. Our API unfortunately requires composing results from many endpoints. Combining this data quickly gets messy, since you have to track and combine loading/error states for each query (nevermind suspense). By comparison, Promises are more composable than hooks and generally better understood by developers.

I don’t think this would lead to too many revalidations because:

• Queries usually have similar stale times, so one query refreshing will kick off a revalidation-chain, basically refreshing everything anyways.
• Loaders typically prepare data for an entire page, so it’s reasonable to assume, that any change in the query cache is relevant to the current route.

Stale while revalidate would still work, because ensureQueryData returns a stale version first and then triggers a second loader run when the data is fresh.

Has anyone attempted the above pattern? Do you think this approach is reasonable?

I'm asking this mostly because #9135 intends to deprecate revalidateIfStale. While this wouldn't completely kill the above approach, it's at least a sign that it's not a common use-case.

[TkDodo]

If it works for you, sure, why not. Just keep in mind that queries that don’t have an observer with useQuery or a similar hook are considered inactive (you can see that in the devtools), which means they are eligible for garbage collection, they won’t be refetched with invalidateQueries automatically etc.

That’s because React Query doesn’t know that you are “using” a query unless you explicitly subscribe to it with useQuery. Subscribing to the whole cache and doing your own thing bypasses this a bit.

[SebKranz]

Thanks. Revalidation would be triggered through the invalidation-api of the router. Same for window focus and interval-based revalidation.

GC is indeed somewhat of an issue. We’ve increased the default gcTime anyways. But if the router revalidates in intervals that are > stale time and < gcTime, the active queries will stay in memory, since GC reschedules after every fetch.

Basically the idea is to offload all the "when to relaod" responsibility onto the router.