Yes, this works. queryClient.invalidateQueries() would also work. But I'd rather invalidate as little as possible which means I have to be specific with the keys. Also you might want to update the cached data after the mutation (Updates from Mutation Responses) instead of just relying on. In those case you will have to use the exact key.
In the end there are a lot of ways to get to the desired outcome (using prefix matching, using the exact option, using predicate functions...). You'd have to choose the solution that works for you. I usually tend to think of solutions that are easy to follow and prevent as many undesirable side effects as possible by design (i.E. they require lower cognitive work).
Yes, this works.
queryClient.invalidateQueries()would also work. But I'd rather invalidate as little as possible which means I have to be specific with the keys. Also you might want to update the cached data after the mutation (Updates from Mutation Responses) instead of just relying on. In those case you will have to use the exact key.In the end there are a lot of ways to get to the desired outcome (using prefix matching, using the
exactoption, using predicate functions...). You'd have to choose the solution that works for you. I usually tend to think of solutions that are easy to follow and prevent as many undesirable side effects as possible by design (i.E. they require lower cognitive work).I'm sure your use-case requires what you describe, for me creating custom query hooks work fine for now.
It really does
That's 138 unique queries, most of which are used dozens of times across the codebase 😅
From my experience I think you have to explicitly pass
{ exact: false }to invalidate partial keys. I could be wrong.