Suggestion to warn against nested QueryClientProviders

[alvarlagerlof]

I just spent an hour debugging the react query devtools because not all of my queries would show up. It turned out to be one QueryClientProvider being inside another causing the issue.

Unless there's a specific use case foe this, I suggest implementing a warning for this.

[TkDodo]

Not sure how this would technically be possible. It’s just react context under the hood, and nesting context providers is valid. Using a context just looks up the nearest provider.

One use case would be to set different default options for a subtree as described here: https://tkdodo.eu/blog/testing-react-query#reactqueryconfigprovider

[alvarlagerlof]

Ah, I understand. Didn't think there would be a real usecase.

[david10sing]

Hi @alvarlagerlof and @TkDodo

I actually have a use case.

I work on a project which uses orval to generate react-query helpers to connect to a backend service. We also have an authentication service which provides a provider with a QueryClientProvider and as @alvarlagerlof I spent half a day debugging until I listed transitive dependencies of @tanstack/react-query, looked for each usage of the dependencies and found the provider from the authentication service.

I think it is also hard to tell if contexts are nested. However, would it be possible to maybe label the query clients? The default could be a uuid but the QueryClient function could also take a parameter called id?

I believe it would really help with debugging.

Any thoughts on this?

[TkDodo]

if the authentication service is yours, I would have it not export a QueryClientProvider. Instead, it can just keep the client local and pass it to all hooks it exposes as a second parameter:

const myClient = new QueryClient()

const useMyAuthHook = () => {
  return useQuery({ queryKey, queryFn }, myClient)
}

That way, consumers can consume the useMyAuthHook without having to use a Provider at all.