check for global queryClient on window

[geoctrl]

for our microfrontend, we have over 30 react apps, and each app can mount simultaneously without a common react root (using single spa).

to use react query, we would need every single react app to be wrapped in a QueryClientProvider, since we don't have a common root.

My proposal is to allow for a queryClient that can be assigned to the window, and read in useQueryClient as a fallback for context.

// src/QueryClientProvider.tsx
export const useQueryClient = ({ context }: ContextOptions = {}) => {
  let queryClient = React.useContext(
    getQueryClientContext(context, React.useContext(QueryClientSharingContext)),
  )

  // just a small little change to allow for a global query client
  if (!queryClient) {
    queryClient = window.__globalQueryClient;
  }

  if (!queryClient) {
    throw new Error('No QueryClient set, use QueryClientProvider to set one')
  }

  return queryClient
}

with this small change, we can avoid wrapping every single react app...

another option is to follow the new v5 API and allow queryClient as an option:

useQuery({
  queryClient,
  ...
});

useQueries({
  queryClient,
  ...
});

useInfiniteQuery({
  queryClient,
  ...
});

useQueryClient({ context, queryClient });

thoughts?

[TkDodo]

as you said, this problem is taken care of in v5:

useQuery({ queryKey, queryFn, ...options }, queryClient)

it doesn't matter where you get the client from - can be passed as a prop or can be read from window.

I'm just wondering: How is adding a another value to every useQuery call better than wrapping all entrypoints in a Provider?

<QueryClientProvider client={window.__globalQueryClient}>
</QueryClientProvider>
``

okay if you have 30 apps, that's 30 providers, but so what? It's 60 lines of code :)

[parkm]

Hey, thanks for the reply! v5 does indeed solve our issue, but we're in a bit of a bind in a few ways. We have a lot of tech debt which is preventing us from upgrading to React 18 (we're actively working on it!) and we're unsure of how long v5 will be in alpha/beta. Although we will have plenty of time to wait for v5's release while we upgrade to React 18, we're also needing a solution for shared queries fairly soon. We've only used it in a few of our services so far but we're wanting to start a full adoption for the rest of our team.

As for passing queryClient to each query call vs using a provider, we not only have 30 services but some of them also export components that can be used by other services. e.g. Our files service exports a file browser that other services can use. In this case if one service is not wrapped in a provider and uses this exported component we'll get a query client not found error. So we also have to wrap all of these shareable components in their own provider until we can ensure that every service is wrapped.

So to allow our team to start gradually introducing react-query it seemed like just passing in the query client explicitly is the safest method for us. We were also thinking of building some global wrappers that will pass in our global client automatically. We're still discussing our options but this is where we're at right now.

[parkm]

@cmacdonnacha At the time of writing that we went with using multiple QueryClientProvider's sharing one queryClient instance for v4. Since then we've upgraded to react 18 and are using v5 of react query, so now we're using a wrapper around useQuery that will pass the global queryClient to useQuery.

[cmacdonnacha]

Appreciate the reply @parkm! Where are you storing the global queryClient?

[parkm]

np! In our case we're using single-spa (would honestly like to move away from that though, but too much of a push atm) and so we have one service that defines the query client and the other services can import it and use it. I'm sure something similar could be done with webpack's federated modules or you could probably even throw it on the window object 🤷

[cmacdonnacha]

We basically have a legacy Rails app and have replaced the traditional rails views with React based pages instead. However, we're using react-rails and that means that each high level component or page is rendered separately and is essentially its own app. For example, we have:

• Header
• Sidenav
• Page content
• Footer

Because each of these is a separate app, they all create their own new QueryClient, kind of similar to micro-frontends. So I would love to have a way to share a single query client with all 4 so we can share data between them. For example when I cause a mutation in the page content, I want the header to reflect that. The hack right now is to reload the browser when we need data to update, but it's not ideal UX.

One simple idea I had was to import queryClient from a shared module and the same instance is shared since ES6 Modules are singletons and the instance is created when the first module is loaded. Just not sure what kind of performance issues or other knock on affects this could possibly have.

// queryClient.ts
import { QueryClient } from 'react-query';

const queryClient = new QueryClient();

export default queryClient;

// Header.tsx
import queryClient from './queryClient';
<QueryClientProvider client={queryClient}>

// PageContent.tsx
import queryClient from './queryClient';
<QueryClientProvider client={queryClient}>

[parkm]

Ah okay yeah that method looks similar to what we were doing when we were using QueryClientProvider. As long as you're able to make sure that each of the apps are using the same version of react query then I think that would work. Not sure of any other caveats that react-rails might throw but that seems like a solid option.