Invalidating query from a different component

[MarekBaraniecki]

I have one component, let's call it View where i use the useQuery hook. Then in a separate component, higher up in the tree, let's say Sidebar I'm using the useQueryClient hook in order to (on some user action) invalidate queries. However, the query list of that QueryClient is empty. I can work with my query only through a QueryClient instantiated in the very same component. Is that expected behavior?

[TkDodo]

as long as they are both under the same QueryClientProvider, it should work fine:

<QueryClientProvider queryClient={client}>
  <View /> <-- does the useQuery
  <Sidebar /> <-- does the useQueryClient
</QueryClientProvider>

[MarekBaraniecki]

That's also what I thought, however this doesn't seem to be the case. Both components are definitely under the same Provider, however the query clients outside of the original function where I am calling useQuery (not a component, but a wrapper hook, something like useFetchPosts) all seem to have empty caches. Are there some known gotchas around that? Because I've used invalidating queries with mutations and everything seemed to work fine and now, with invalidation on user action the caches are empty and for the life of me I can't figure out why.

[TkDodo]

I don't know how you determine that they have an empty cache. Are you using queryClient.getQueryData(key) to retrieve some data? If so, make sure that you are using the same query key - you will get undefined otherwise.

Please create a codesandbox example that shows your issue, because I can assure you - within the same QueryClientProvider, you do have access to the cached data regardless of component structure.

[MarekBaraniecki]

getQueryData as well as sneek peeking through debugger (queryMap empty). Yes, I realize that my question is not very clear nor precise, I will try to reproduce it shortly. Thank you for the swift replies.

[MarekBaraniecki]

I write just to provide some closure: The issue seems to be that I declared QueryClient inside of the render method of App, not in global scope, which was causing some unexpected behavior (not all hook invocations sharing the same object). An embarrassing mistake, although I'm slightly surprised, that the library didn't throw any errors.