Query key choice for join-like queries

[changesbyjames]

As asked by @TkDodo, I've re-posted this on here for posterity.

I'm not sure how to specify the query keys in a way that makes invalidation sensible to achieve in a join-like situation.
I essentially have a request that does a join, e.g.

useQuery({
  queryKey: ['/table/a/rows', '/table/b/rows'],
  queryFn: async () => {
    const a = await get('/table/a/rows')
    const b = await get('/table/b/rows')
    return joinInSomeWay(a, b)
  }
})

If I update table a, that's easy: client.invalidateQueries(['/tables/a/rows']) for a non-exact match.
But if I update table b, I'm not sure what the best approach would be?

[artem-malko]

Maybe you should create one more entity with an appropriate name? And that new entity should have its own invalidate-function.

[changesbyjames]

Yes, that would work for that example but I think I over-simplified my use case, the two tables are inextricably linked in the request e,g.

useQuery({
  queryKey: ['/table/a/rows', '/table/b/rows'],
  queryFn: async () => {
    return getAndJoinTwoTables('/table/a/rows', { foreignKey: 'id', foreignTable: '/table/b/rows' )
  }
})

[artem-malko]

Yeap, I understand your case. But the idea, that you need another entity for your query is not only for react-query) It's a good pattern for your application too.

So, in your case I'd create:

1. A query like in your example, but with a certain key. Let's say ['table-a-b']
2. A specific invalidate function for each table. Something like:

export const useInvalidateTableA = () => {
  const client = useQueryClient();
  
  return useCallback(() => {
    client.invalidateQueries({ queryKey: ['/table/a/rows'] });
    client.invalidateQueries({ queryKey: ['table-a-b'] });
  }, [client]);
}

You need a better naming) Cause I don't know your business terms. And the same function for useInvalidateTableB.

The main idea here is to separate business cases.

But yeah, it's better to wait for @TkDodo answer)

[TkDodo]

I see two ways to achieve this:

Object Query Keys

Array Query Keys have a hierarchy, so in your case, /table/a/rows is a parent of '/table/b/rows'. But that isn't really their relationship according to your requirements, they are kind of siblings. What happens if we change the keys to:

useQuery({
  queryKey: [{ a: '/table/a/rows', b: '/table/b/rows' }],
  queryFn: async () => {
    const a = await get('/table/a/rows')
    const b = await get('/table/b/rows')
    return joinInSomeWay(a, b)
  }
})

Now, a and b are siblings, because objects have no hierarchy. With that, you can do:

queryClient.invalidateQueries([{ a: '/tables/a/rows' }])

as well as

queryClient.invalidateQueries([{ b: '/tables/b/rows' }])

and both will invalidate the one entry you have. I've written about this pattern here: https://tkdodo.eu/blog/leveraging-the-query-function-context#object-query-keys

useQueries with combine

Another question that came to my mind is: why do we have one query that fetches both table/rows instead of two queries. Seems like each one should be their own resource. With the new v5 combine function, we can get a quite optimized way to only re-fetch what you really want to invalidate and to re-render your component only if the result of joinInSomeWay changed:

useQueries({
  queries: [{
    queryKey: ['/table/a/rows'],
    queryFn: () => get('/table/a/rows')
  }, {
    queryKey: ['/table/b/rows'],
    queryFn: () => get('/table/b/rows')
  }],
  combine: ([a, b]) => joinInSomeWay(a, b)
})

This also has the advantage of a and b being stored as separate queries, so if you update table b, you can do: queryClient.invalidateQueries('/table/b/rows'). This will only refetch table b, while the single useQuery one will also refetch table a, as the whole queryFn needs to run and it awaits both calls.

---

I'd choose the useQueries option with combine if you're already on v5.

[artem-malko]

Quite cool idea with an object as queryKey) Thx