Invalidating a dependant query chain

[vitalybe]

In one of my components I fetch data from 3, dependant, queries:

const dataA = useQuery("a", () => "A")
const dataB = useQuery("b", () => dataA.data + "B", {enabled: !!dataA.data})
const dataC = useQuery("c", () => dataB.data + "C", {enabled: !!dataB.data})

That works as expected. However, in an editor, in another window, I modify data in a query and I would like to invalidate it:

queryClient.invalidateQueries("a")

As expected a gets invalidated and the data is refetched. However, b and c are not so they both would still return data that relies on the old instance of a.

The only solution I have now is to invalidate ALL the dependant queries:

queryClient.invalidateQueries("a")
queryClient.invalidateQueries("b")
queryClient.invalidateQueries("c")

Not only do I need to specify them all, but I also need to specify them in a very specific order. If I invalidate c before a the resulting useQuery would run immediately and incorrectly cache in c the old value of a.

Is there a better solution?

[TkDodo]

use deterministic query keys which communicate that they all belong together and use the fuzzy matching to invalidate at once:

const dataA = useQuery(['data', 'a'], () => "A")
const dataB = useQuery(['data', 'b'], () => dataA.data + "B", {enabled: !!dataA.data})
const dataC = useQuery(['data', 'c'], () => dataB.data + "C", {enabled: !!dataB.data})

queryClient.invalidateQueries(['data'])

---

alternatively, I think you could disable B and C while dataA.isFetching. So when you then invalidate only A, B and C would go to disabled state, and then switch back to enabled once A has data, which should trigger a refetch. I'm not 100% certain of this flow - would be cool if you'd try that out :)

[vitalybe]

Thanks for the swift reply!

Fuzzy matching is an interesting idea! I am a bit concerned about the mistakes that could arise in more complicated cases. Consider a dependency of multiple paths from multiple components that some of them rely on the same query. Managing a "path" using query keys sounds a bit error-prone.

alternatively, I think you could disable B and C while dataA.isFetching. So when you then invalidate only A, B and C would go to disabled state, and then switch back to enabled once A has data, which should trigger a refetch. I'm not 100% certain of this flow - would be cool if you'd try that out :)

I'm afraid that doesn't work, here is a code sandbox with a sample: https://codesandbox.io/s/react-query-depency-using-enabled-i2t0d

---

I might be over-engineering here, but it seems like quite a common use case.

I had a crazy idea of using a graph data structure to build the relationship dynamically, by usage. Then use that information to invalidate the queries. If that sounds interesting, I'll post an example.

[TkDodo]

I'm afraid that doesn't work, here is a code sandbox with a sample:

it would work, except that you have a staleTime set for your queries. When a query transitions from disabled to enabled, a background refetch will happen for stale queries. It basically counts as a "mount". Remove the staleTime from your example and it works.

[vitalybe]

Remove the staleTime from your example and it works.

But I do want to use stale - The whole idea is to reuse specific parts of the application data in cached and shared between different containers.

I made some original attempt at this issue and I quite like the design that came out:

https://codesandbox.io/s/react-query-dependancies-hnnp4?file=/src/providePrepareResult.tsx

The basic idea here is to wrap every "provider" logic inside a custom Provider structure that will invoke useQuery on it and assign its key. The dependency are kept in a graph structure using "graph-data-structure" which allows smart invalidation of related items.

In the example above the component is using ProviderC whose date relies on ProviderB, which relies on ProviderA. And still, you can easily invalidate either ProviderA (using invalidateQueriesRelyingOnMe function) or invalidate ProviderC and ALL the queries it relies on (using invalidateQueriesSelfReliesOn function)

I hope that it makes sense and it helps someone.