Detected multiple Jotai instances. It may cause unexpected behavior with the default store.

[fabio-nettis]

I suddenly am encountering this error after upgrading to Next.js v13.4.13 from the previous version. My root layout.tsx file includes a provider for Jotai, thats the only place in the application the provider can be found. Here is the code of the provider component:

"use client";

import { Provider } from "jotai";
import store from "global/store";

interface Props extends React.PropsWithChildren {}

export default function JotaiProvider({ children }: Props): JSX.Element {
  return <Provider store={store}>{children}</Provider>;
}

export type { Props as JotaiProviderProps };

Here I am simply passing the store created in "global/store" and wrapping the rest of the children with it. Here is the code that creates the store.

import { getDefaultStore } from "jotai";

const store = getDefaultStore();

export default store;

Am I doing something wrong here? This error may be related to the fix #2066, but again that is just a wild guess.

[dai-shi]

That's exactly the case the warning is trying to detect.
Using getDefaultStore() assumes single Jotai instance.

If you are using Nextjs, it's recommended to avoid using the default store.

-   return <Provider store={store}>{children}</Provider>;
+   return <Provider>{children}</Provider>;

[fabio-nettis]

That did the job, my bad, thank you.

[anshul-kai]

Removing the store prop from the Provider throws the following error. Adding it removes it. Is the above fix still valid for Next.js projects?

Detected multiple Jotai instances. It may cause unexpected behavior with the default store. https://github.com/pmndrs/jotai/discussions/2044

Regardless, it looks like there is more than one store as updates aren't always propagating to other components as one would expect.

[IsmailKemmoune]

@dai-shi I have a question please, doesn't wrapping the root layout in case of next js app router and marking it as a client component, makes my whole app a client component? since all the sub components gonna be client as well?

[dai-shi]

Yeah, that's why you want to use Provider in a server component. Or, you can create your own client component that receives a server component as a children prop, which avoids making the whole app a client one.

[dai-shi]

@anshul-kai

Is the above fix still valid for Next.js projects?

It depends on your requirement, but in general, SSR framework like Next.js shares memory across multiple sessions and you want to make sure to use different store for each session. Removing store prop will create a new store for each session.

[dbritto-dev]

@dai-shi yeah, seems is also HMR'd

[dai-shi]

If <Provider> is HMR'd, the warning should be shown, as something unexpected can really be happen.

So the question is if there's a way to avoid HMR'ing the layout file when we only edit the page file.

[dai-shi]

Wait, that's still weird. Are you somehow using atom outside <Provider> tree?

[dbritto-dev]

@dai-shi no, all the components should be inside the <Provider> tree

[dbritto-dev]

@dai-shi I'll create a stackblitz minimal repro