Unable to use more than one apps with QueryClientProvider on page

[NZainchkovskiy]

Describe the bug
In my scenario I need to host more than one react application on one page.
Each of app uses react-query v3, app wrapped with QueryClientProvider (I can reproduce it with CRA apps with just your "overview" sample code (https://codesandbox.io/s/github/tannerlinsley/react-query/tree/master/examples/simple)).
When I open page with these apps, only one of them running fine, and others fails with error:
No QueryClient set, use QueryClientProvider to set one
Maybe it's because of using window.ReactQueryClientContext for context storage of app, what makes impossible to use many react-query context on one page with many apps (https://github.com/tannerlinsley/react-query/blob/master/src/react/QueryClientProvider.tsx#L9).

If I use just one app with many QueryClientProviders it's works ok.

If you can suggest any workarounds for this issue, I will appreciate it. Thank you.

To Reproduce
Steps to reproduce the behavior:

1. Build 2 apps with example from here: https://codesandbox.io/s/github/tannerlinsley/react-query/tree/master/examples/simple
2. Host these 2 apps with one html page (I just build two CRA apps and then add div and scripts from one app index.html to another).
3. Serve this overall html (I did just serve -s build).
4. See error. First app crashes, but second runs fine.

Expected behavior
Every separate apps runs without react-query related errors and with react-query functionality.

Additional context
I tried to add some timeout for render of second app, and it's works but only for the first serve of html. Than, after page reload errors returns.

setTimeout(() => {
  ReactDOM.render(
    <React.StrictMode>
      <App />
    </React.StrictMode>,
    document.getElementById("app2")
  );
}, 1000);

[sec0ndhand]

I have the same issue, we have a rails app that we are slowly moving over to react and this has been a problem since we upgraded to v3. Love the library, let us know what we can do to help!

[NZainchkovskiy]

I think simpliest solution will be adding optional property to QueryClientProvider and using it for placing context to window.
So for such edge cases one can use unique window property for each application.

There is quick and dirty concept. I think it's far from ideal and maybe @tannerlinsley will suggest something better, but for the idea:

import React from 'react'

import { QueryClient } from '../core'

const defaultClientContextName = "ReactQueryClientContext";

const QueryClientContext = (() => {
  const context = React.createContext<QueryClient | undefined>(undefined)
  if (typeof window !== 'undefined') {
    // @ts-ignore
    window[contextName ?? defaultClientContextName]  = context
  }
  return context
})()

function getQueryClientContext(contextName?: string) {
  return typeof window !== 'undefined'
    ? // @ts-ignore
      (window[contextName ?? defaultClientContextName] as React.Context<
        QueryClient | undefined
      >) ?? QueryClientContext
    : QueryClientContext
}

export const useQueryClient = (contextName?: string) => {
  const queryClient = React.useContext(getQueryClientContext(contextName))

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

  return queryClient
}

export interface QueryClientProviderProps {
  client: QueryClient
  contextName?: string
}

export const QueryClientProvider: React.FC<QueryClientProviderProps> = ({
  client,
  contextName,
  children,
}) => {
  React.useEffect(() => {
    client.mount()
    return () => {
      client.unmount()
    }
  }, [client])

  const Context = getQueryClientContext(contextName)

  return <Context.Provider value={client}>{children}</Context.Provider>
}

[TkDodo]

Why do we have to attach the queryClient to the window at all @tannerlinsley @boschni ? And why is useQueryClient using that window.ReactQueryClientContext to look it up? Should this not just be:

- const queryClient = React.useContext(getQueryClientContext())
+ const queryClient = React.useContext(QueryClientContext)

[boschni]

Tracked it down to: e8a22e9 .

Looks like this was added to support multiple react query versions in one app but I don't know the specifics.

[tannerlinsley]

I'm looking into the issue right now. This was originally necessary for React Query's context to survive beyond different bundle boundaries, otherwise, the React.context reference would be created once for each bundle involved. If React context could work by matching up context by unique ID and not equality === 🤦‍♂️, this wouldn't be an issue.

I'll report back in a bit.

[tannerlinsley]

So far, I haven't been able to reproduce this in the way you described.
Here is a codesandbox of my reproduction attempt: https://codesandbox.io/s/nice-water-y5ojm?file=/src/index.js
And this is its deployment to vercel in production: https://csb-y5ojm-o3y0wov6c.vercel.app/

The deployment seems to be working as expected with no issues, however I did notice the following error:
No QueryClient set, use QueryClientProvider to set one
When in development mode and when hot reloading to a new state in the app.

[tannerlinsley]

It's my birthday today, so I'm going to put a pin in this one and check back tomorrow. If anyone can nail down the reproduction any better, let me know!

[NZainchkovskiy]

There is reproduction (release bundles deployed to netlify): https://react-query-issue-demo.netlify.app/
Key difference that there is two separate bundled apps, placed to one html pages.
As you can see, there is only App2 rendered, and there is errors in console.
If you want, I can push the repos with source code, but it's basically CRA with typescript bootstrapped code with App.tsx changed to your demo. App1 rendered to div with "app1" id, and app2 rendered to div with "app2".
Our scenario: separated react apps, hosted at asp.net web application.
There is another scenario - SharePoint Framework web parts for using with SharePoint Online.
SharePoint and Microsoft Teams is huge and growing enterprise platform with large developers community. I think I am a biggest fan and advocate of react-query in Russian SharePoint developers community, and if I can help somehow to bring ability of using v3 of react-query in that scenarios, I will be happy to do that.

[tannerlinsley]

I see. I’ll have to dig into this tomorrow.

[NZainchkovskiy]

Thank you. Happy birthday!

[etoxin]

Happy Birthday! This is an amazing library. Thank you so much.

We have a micro frontends build with multiple react apps in a single DOM. We are also getting this exact issue.

I hope you have an amazing Birthday.

[adamlusted-swipejobs]

If React context could work by matching up context by unique ID and not equality === 🤦‍♂️, this wouldn't be an issue.

you may be able to leverage displayName in the context.

const MyContext = React.createContext(/* some value */);
MyContext.displayName = 'MyDisplayName';

https://reactjs.org/docs/context.html#contextdisplayname

[tannerlinsley]

That would help the display name in the devtools, but not the larger issue unfortunately. Tanner Linsley

…

On Feb 10, 2021, 4:52 PM -0700, Adam Lusted ***@***.***>, wrote: > If React context could work by matching up context by unique ID and not equality === 🤦‍♂️, this wouldn't be an issue. you may be able to leverage displayName in the context. const MyContext = React.createContext(/* some value */); MyContext.displayName = 'MyDisplayName'; https://reactjs.org/docs/context.html#contextdisplayname — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[vago]

Hi, not adding much to the discussion, except for +1'ing the issue. We are also in a similar situation. We are evaluating RQ and are pretty impressed with it, but this use-case is kind of a show-stopper for us to continue. Hopefully, the fine guys behind RQ will come up with a solution soon 👍

[TkDodo]

@tannerlinsley we are also in the process of using multiple microfrontends on the same page, each one using / wanting their own QueryClientProvider, son I’m sure we’ll see the issue as well quite soon.

I haven’t fully understood the need for attaching to the window yet, but if we need that, I think the optional context name suggested by @NZainchkovskiy would work. It could alternatively also maybe be a name/id field on the QueryClient itself.