ContextSharing not working for different modules

[reh2ur]

Describe the bug
When using the QueryClientProvider in an npm package and requiring the query client via useQueryClient in the consumer app, I am always getting the following error:

Error: No QueryClient set, use QueryClientProvider to set one

It seems like the logic for getting the shared context is broken.

Expected behavior
Using the useQueryClient should check for the shared ReactQueryClientContext and use it if existing.

Additional context
With #1912 the context sharing was disabled by default, and seems to have been disabled at all.
It seems like the QueryClientSharingContext is always false, as it is initialized with that value:
https://github.com/tannerlinsley/react-query/blob/05a8057e2be64915d2a12b716d8131f113598dbd/src/react/QueryClientProvider.tsx#L12
https://github.com/tannerlinsley/react-query/blob/05a8057e2be64915d2a12b716d8131f113598dbd/src/react/QueryClientProvider.tsx#L34

Shouldn't the context be initialized with whether there is a shared context or a boolean value, passed to the useQueryClient hook?

[TkDodo]

right, I think you'd need a QueryClientProvider to turn contextSharing on, which kinda defeats the purpose 🤔 . Can you create a codesandbox example that works with a version before #1912 was merged and doesn't work with the latest version? Thanks.

[reh2ur]

Thanks for the quick reply! Actually I found the issue: I had a higher version of React-Query in my peer dependencies for my npm module. That's why it wasn't using the same version in both projects. Took me a while to figure that out...
Sorry for any inconveniences and never mind :)

[TkDodo]

okay cool, but maybe I'm not fully understanding contextSharing then 😅 . Can you maybe tell me what you are doing with it and how it works for you? Does it allow you to call useQuery without being in a QueryClientProvider ?

[reh2ur]

Sure thing!
We are experimenting with extracting shared logic from multiple NextJS projects into an internally used library. I am trying to create a reusable Wrapper component that encapsulates UI elements as well as support for data fetching. This <Wrapper /> would take care of rendering the QueryClientProvider with an appropriate client, so that the consumer - as a child of Wrapper - could just call useQuery without having to deal with the actual client.

The library has react-query as a peer dependency, which is why the useQuery hooks of the consumer app and the QueryClientProvider of our shared module have the same react-query instances.

Of course, if the peer deps version does not match with the consumer version, webpack will use two different instances for both of them, which is why the context was not shared 😅

[vsylvestre]

@reh2ur I'd be curious to have more details as to how you fixed this, since I'm in a very similar situation.

We have a “shared library” which is imported as a package in various projects within a monorepo. I‘m trying to transfer what we call the DataFetchingLayer component, which contains the logic to instantiate the query client and wraps everything with QueryClientProvider, into that library to be shared by the different projects. However, I get the same error you mentioned in your OP, caused by the use of useQuery in the projects that import the library. The only way I can fix this is by having another QueryClientProvider on the projects’ side, which kind of defeats the purpose of having it in a shared library.

Similarly to your situation, we have react-query as a peer dependency in the library. But the version is the same as that of the projects‘. They‘re all bundled with Webpack, so I added react-query as an “external” in my Webpack config, and that didn‘t help. I tried bumping react-query to the latest version for all of them, but that didn‘t work either.

Did you happen to do anything else other than making sure that the versions matched?

[scottdickerson]

this is exactly what we're trying and this is still happening for me as well @vsylvestre and @reh2ur, details here: #3697

I checked the react-query versions, they are the same between consumer and provider as well, peerDependencies and devDependencies on the MFE provider of react-query: 3.39.1, and dependencies on the consumer side of react-query: 3.39.1

[TkDodo]

you'd need to provide a reproducible example of some sorts please.
also, in v4, there is the option to pass a custom query context for scoped providers. Have a look at the example in the migration guide: https://tanstack.com/query/v4/docs/guides/migrating-to-react-query-4#custom-contexts-for-multiple-providers

[scottdickerson]

I was able to force both MFEs to use the same react-query instance which fixed this issue:

 const config: ModuleFederationPluginOptions = {
 name: userConfig.moduleName,
 filename: 'remoteEntry.js',
 remotes: getRemotes(userConfig),
 exposes: userConfig.exposes,
 shared: {
 ...packages.dependencies,
 react: {
 singleton: true,
 requiredVersion: '>= 16.14.0',
 },
 'react-dom': {
 singleton: true,
 requiredVersion: '>= 16.14.0',
 },
 'react-query': {
 singleton: true,
 requiredVersion: '>= 3.39.1',
 },
 },
 };

[petejodo]

I do think context sharing is broken and that's because the QueryClientSharingContext is created across all instances of react-query and so the sharing context itself isn't shared. That context is the way the value passed in for contextSharing in QueryClientProvider by passing it into that shared context's provider.

That's how useQueryClient knows to use context sharing

Here's what a fix could maybe look like

[TkDodo]

I'm honestly pretty unsure what contextSharing is and what it's supposed to be doing. Is it necessary / useful to anyone? Isn't the new feature in v4 enough where you can pass a custom context around? If so, I would be in favour of deprecating it ...

[petejodo]

yeah I'm not sure. What's weird is that it's not absolutely clear how you'd use either feature. Because providers are rendered at the top of the tree, in a microfrontend setup every separate module would still have to be passed the context, check if a context was already provided and if not, render a provider. This could be done very similarly without passing context though and just be done with only the client. Here's the example of a module's provider:

import React from 'react';
import { QueryClient, QueryClientProvider, useQueryClient } from '@tanstack/react-query';

type ProviderProps = {
 children: React.ReactNode;
 client: QueryClient;
};

export default function Provider({ children, client }: ProviderProps) {
 try {
 useQueryClient();
 return children;
 } catch (_e) {
 return (
 <QueryClientProvider
 // if client instance types match, then we know the same version of react-query got loaded
 // otherwise just create a new client for this module
 client={client instanceof QueryClient ? client : new QueryClient()}
 >
 {children}
 </QueryClientProvider>
 );
 }
}

with context getting passed, it would look very similar:

import React from 'react';
import { QueryClient, QueryClientProvider, useQueryClient } from '@tanstack/react-query';

type ProviderProps = {
 children: React.ReactNode;
 client: QueryClient;
 context: React.Context<QueryClient | undefined>;
};

export default function Provider({ children, client, context }: ProviderProps) {
 try {
 useQueryClient({ context });
 return children;
 } catch (_e) {
 return (
 <QueryClientProvider
 client={client instanceof QueryClient ? client : new QueryClient()}
 // if a client is provided from above but none exists in context and client instance types match
 // add it to the provided context
 context={client instanceof QueryClient ? context : undefined}
 >
 {children}
 </QueryClientProvider>
 );
 }
}

and so I'm not exactly sure what the purpose of context is either. And actually the example without context is a bit nicer because it prevents the need for passing it to all usages of useQueryClient

Edit the non-context example does however break react query devtools

[ecyrbe]

you'd need to provide a reproducible example of some sorts please. also, in v4, there is the option to pass a custom query context for scoped providers. Have a look at the example in the migration guide: https://tanstack.com/query/v4/docs/guides/migrating-to-react-query-4#custom-contexts-for-multiple-providers

So like i said on V5 discussion context sharing is used in the context of microfrontends.

Big picture here :
Context sharing allows users of microfrontend to evoid handling context instanciation manually and run into issues of which one should share the context. More elaborate answer on this in v5 discussion.

Now context isolation is an option if handled by each microfrontend to override the default react-query context instance.
But it would be bad for performance reasons.
Users of microfrontend will indeed prefer to share context to take advantage of shared cache and evoid duplicate request of common server states. For this to work, you then need to have some kind of key normalisation in your project.

So you need to either:

• activate today shared context for react to be happy else react tells you that context already exists (react need to be a shared singleton library to work properly in microfrontends)
• instanciate an isolated context in your microfrontend (haven't tried this option yet, performance concerns)
• instanciate a shared context in a singleton shared library (with Module Federation ) that is a superset of react-query. This common library would need to do what react-query does today with context sharing. So reinvating the wheel in each project with the possibility of doing it badly. (haven't tried this option yet)

[TkDodo]

@ecyrbe I'm not entirely sure how you've setup microfrontends, but why wouldn't the hosting application just create the QueryClient and the Provider, and it would then be picked up by the microfrontends when they call useQueryClient ?

Are the microfrontends mountings themselves to different roots? If so, creating the context and passing it to the microfrontends as shown in the custom-contexts docs should work? Albeit a bit more boilerplate as every call to useQuery / useQueryClient would need to use that context ...

I just have the feeling that taking the context and putting it onto the window object is also a bit dirty.