Sharing state with library component

[cooltolia]

Hey all.
First of all let me say thanks for an amazing library.

On the current project I faced the following problem.
We have separate npm package with react components. They are imported by core application and then rendered consuming some props.
But the communication is so coupled that I was thinking about moving the logic to some external service, like Jotai.

I tried to create an atom and export it from npm package. And than use it in core to set some value.
The question I have is how to make a package to get these changes inside it's component. For now as I understand useAtom in core and npm package are referencing two different instances of atom.

Tried using the Provider component, but maybe doing something wrong.

Would appreciate any help.

[dai-shi]

For now as I understand useAtom in core and npm package are referencing two different instances of atom.

That can happen, but not exactly sure how in your case.

For the library use case, it's highly recommended to use store and export a custom provider and custom hooks from your library, if you want to hide Jotai internally.

Tried using the Provider component, but maybe doing something wrong.

Can you reproduce it without the library? Maybe with https://csb.jotai.org

[cooltolia]

Hello @dai-shi. Thanks a lot for a such quick reply.

https://codesandbox.io/s/red-snow-ffm8xp?file=/src/App.tsx
This is very dump example I am currently trying to achieve. The main difference is that /sharedLibrary is meant to be an external npm package in my case. And in that scenario the following example is not working.

or the library use case, it's highly recommended to use store and export a custom provider

I met this advices too, but code samples were for jotai v1. Could you please share some minimal code example I could get the main idea?

[dai-shi]

And in that scenario the following example is not working.

Can you elaborate what's the expected behavior and how it's not working?

[cooltolia]

Sure. As mentioned previously /sharedLibrary from the example above is an npm package in my case. I build and link it to the core app during the development process.

Expected behavior would be just the same as in example.
Actual behavior: setting new value for atom in core app component doesn't trigger value update and rerender in library component.

As I understand that's because I actually end up with atoms of the same config but two different instances.

But maybe I am wrong and it should still work and the problem somewhere else on the project level.
If you say that it still should work, I would try to create a bare minimum project setup to reproduce an issue.

[cooltolia]

Oh, I've just realized that store has been introduced in v2 :)
But still would be grateful for some guidance if possible

[dai-shi]

const store = createStore();

const countAtom = atom(0);

export const CustomProvider = ({ children }) => (
  <Provider store={store}>
    {children}
  </Provider>
);

export const useCustomHookCounter = () => {
  return useAtomValue(countAtom);
};

[cooltolia]

Frankly speaking with this example it is not really clear what is the purpose of providing store. Do I need then read something from it?

[cooltolia]

Ok, finally it worked, and turned out all I had to do is to use custom hook from the example inside core app. With that change everything is working.
But as much I'm happy as much frustrated being unable to understand why this change actually resolves the issue?

[dai-shi]

Provider uses React Context internally, and useAtomValue by default uses the store in the context.
Alternatively, you can pass the store directly to the hook.

  useAtomValue(countAtom, { store })

In that case, you don't need Provider.

[cooltolia]

Hello @dai-shi.
Just wanted to share the result of my research and say thanks for your help.
With your answers I started better understand the library plus it helped me with reading its source code.

As a result, the problem I shared is mostly related to the way how my projects are built.
Having two projects: core and feature package I ended up with loading two copies of jotai. Each used useAtom from its node_modules.
And with custom hook we actually set closure on usage of useAtom from one place.

Eventually it was easier simply set webpack alias for jotai to resolve it from direct node_modules and alway have only one source of library

[cooltolia]

If you find it valuable. The react has this kind of check with throwing an error about wrong usage of hooks.

[dai-shi]

If I create a PR, can you check if that can help your (wrongly configured) case?
You will be able to npm install the PR's build.

[cooltolia]

Yes, sure

[dai-shi]

Here you go: #2049

https://ci.codesandbox.io/status/pmndrs/jotai/pr/2049
☝️ Find "Local Install Instructions"

[cooltolia]

Yep, validated, warning is present:

[KDederichs]

I'm getting that warning as well now... though I only have ONE provider at the very top of my NextJS app.
Could it be that this persists between hot reloads and then triggers the warning?

[dai-shi]

Oh, good point. Though, I'm not sure if the library part is hot reloaded.
It doesn't warn on the initial load, and only warns on hot reloads? (every time?)

[itsjoeoui]

Yepp I can confirm as well, also NextJS with app router, same problem. Warning happens after every hot reload but not on initial load

[dai-shi]

The warning is still valid if you are using the default store, but NextJS users should use Provider, and you probably don't use the default store, so, it's not necessary. Let me draft a PR.

[dai-shi]

Can you guys try #2061?
https://ci.codesandbox.io/status/pmndrs/jotai/pr/2061
☝️ Find "Local Install Instructions"

[Caracolaracol]

Can you guys try #2061? https://ci.codesandbox.io/status/pmndrs/jotai/pr/2061 ☝️ Find "Local Install Instructions"

I'm also having this issue with nextJS, tried the #2061

[dai-shi]

Do you use getDefaultStore?

[shinchima]

No, I don't

[dai-shi]

Hmmm, that's weird because the warning message only exists in the function. Or, is your question something other than this warning message?

jotai/src/vanilla/store.ts

Lines 798 to 811 in 1d004b0

	export const getDefaultStore = () => {
	if (!defaultStore) {
	if (
	import.meta.env?.MODE !== 'production' &&
	(globalThis as any).__NUMBER_OF_JOTAI_INSTANCES__ !== 1
	) {
	console.warn(
	'Detected multiple Jotai instances. It may cause unexpected behavior with the default store. https://github.com/pmndrs/jotai/discussions/2044'
	)
	}
	defaultStore = createStore()
	}
	return defaultStore
	}

[dai-shi]

Oh, I see. I think you use the default store indirectly. You want to use <Provider> with nextjs.

[shinchima]

OK gotchya,
Thanks for being so responsive, much appreciated.

[KDederichs]

Version 2.3.0 seems to fix it, thanks :)

[abdulbari149]

Hi, I am having the same error, without using getDefaultStore or something. I am just creating a store with createStore and passing it as a prop to the Provider. I am using jotai with react-native

[dai-shi]

What's the error exactly?

[Nubebuster]

I dont fully understand the issue. I have a atoms.tsx where I have two atoms that I use in many places using the useAtom hook. I get this jotai notification and I dont know whether to ignore or if I should take action

[digoburigo]

One thing that I noticed if the React strict mode is off, this warning don't show for me at least

[Nubebuster]

Well, that probably solves it once and for all. We can ignore this warning as it's a side effect of React's strict mode. That makes sense.

[zecka]

I got this issue issue in a next js application that consume an npm package that also use jotai.
The npm package is linked via yarn link (not sure if it's related)

I add following config in next.config.js to fix issue

const nextConfig = {
    webpack: (config, _context) => {
      config.resolve.alias['jotai'] = path.resolve(__dirname, 'node_modules/jotai')
      return config;
    },
}

Note that I got a similar issue with multiples instances of React (vercel/next.js#50391)

[lveillard]

I'm facing exactly the same issue and i'm not getting the "Detected multiple Jotai instances` warning

We have this setup (pnpm + turborepo)

• app/nextjsApp1
• app/nextJsApp2
• package/JotaiEngine with atoms initialization
• package/SharedReactComponents, one shared lib of components which imports jotaiEngine as well

I want both nextjsApp to be independent, so they have their own provider and store ( )

The sharedReactComponents are built with tsup but they are just like a dummy shared folder.
The 2 apps and also the sharedReactComponents use the atoms defined in the jotaiEngine

When copy-pasting the components from the shared React Components libs to each of the apps, the atoms do work, however, calling them from the sharedReactComponents is useless as they are empty.

SOLVED:
I fixed it by adding jotai as a peer dependency in both the jotaiEngine and the reactSharedComponents. So each one of the nextjs apps are in charge of jotai even if the engine inits them.

[jelling]

I was also trying to share state between a library and an app and switching jotai to a peer dependency in the library fixed the issue. Since that's a less common usage of npm, here's an example:

In your library package.json, switch this:

  "dependencies": {
    "jotai": "^2.6.0"
  },

to:

  "peerDependencies": {
    "jotai": "^2.6.0"
  },

[Orpheus29]

Yes, this solved that problem for me.

[fjcalzado]

I'm also experiencing this issue as others say.

In my case is even simpler: single project in providerless mode, but I can see the warning triggered from my unit tests execution with jest and @testing-library. Is it just a 'false positive'? Cause I don't think I have 2 jotai instances in this scenario.

UPDATE: I can confirm that:

• Running my project, __NUMBER_OF_JOTAI_INSTANCES__ is 1,
• However, running unit tests, __NUMBER_OF_JOTAI_INSTANCES__ is 2,

So, this might do the trick:

(globalThis as any).__NUMBER_OF_JOTAI_INSTANCES__ = -1;

if placed in jest setup file. However this is just hacking, I wonder why the store code is executed twice when running tests.

[Nubebuster]

Running that code just hides the problem. But I reckon we can all ignore the problem as I have not seen anyone complain of any side effects. It's just a warning.

[fjcalzado]

Agree, is just a hack. I was trying to understand why jotai believes there are 2 instances.

[dai-shi]

#2462 might have improved it.

[x0s3]

in case someone encounters this problem using jest.isolatedModules, the solution I found was as follows:

let mockActualJotai: typeof import("jotai");
jest.mock("jotai", () => {
  if (!mockActualJotai) mockActualJotai = jest.requireActual("jotai");
  return mockActualJotai;
});

[assertnotnull]

This warning also shows in an Expo app in providerless mode.

[dai-shi]

That sounds bad unless it's caused by hot reload or something dev-only.

[tval2]

I get this warning every time I reload the page in my next.js project (but doesn't go away if I turn off strict mode)

[dai-shi]

This is the warning to let you know that you forgot to use <Provider> in Next.js projects. The warning message doesn't specifically say that because it's not always the case.

jotai/docs/guides/nextjs.mdx

Lines 52 to 68 in 7d4da51

	### Provider
	By default, Jotai uses an implicit global store to keep track of atom values. This is what is referred to as "provider-less" mode. This becomes an issue in SSR scenario because this global store is kept alive and is shared between multiple requests, which can lead to bugs and security risks.
	To limit the lifetime of the store to the scope of one request, you need to use a [Provider](../core/provider.mdx) at the root of your app (or a subtree if you're using Jotai only for a part of your application).
	```typescript
	import { Provider } from 'jotai'
	function App({ Component, pageProps }: AppProps) {
	return (
	<Provider>
	<Component {...pageProps} />
	</Provider>
	)
	}
	```

[tval2]

oh interesting. If I'm using the newer app router next architecture do you know if this goes in layout.tsx:

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body className={inter.className}>
         <Provider>
           <AppRouterCacheProvider>{children}</AppRouterCacheProvider>
         </Provider> 
      </body>
    </html>
  );
}

vs. page.tsx

export default function Home() {
     return ( 
     <Provider> 
       <Component {...pageProps} /> 
     </Provider> 
   ) 
}

? or does it not matter?

[dai-shi]

It depends. <Provider> will separate the stores.

See also: #2688 #2692

[tval2]

Got it, based on that since I have a small application I put it in layout.tsx. For anyone else encountering that issue it look like this:

  return (
    <html lang="en">
      <body className={inter.className}>
        <Provider>
          <AppRouterCacheProvider>{children}</AppRouterCacheProvider>
        </Provider>
      </body>
    </html>
  );

[tval2]

wait I take this back. I still get Detected multiple Jotai instances. It may cause unexpected behavior with the default store

[tval2]

It is odd, even with the Provider wrapped around my entire app when I call store.set(isProcessing, true); in a utils function and confirm this is setting it correctly; then in my other component calling const isProcessing = useAtomValue(isProcessingAtom); returns false. I'll keep digging but am likely missing something here.

[dai-shi]

Maybe, you want to open a new discussion as it's slightly different from the OP, and it seems Next.js specific.

[dbritto-dev]

@dai-shi I believe is something related to React Refresh if happens only on development using nextjs

[calvinusesyourcode]

For those who come after me!

I'm in NextJ2 14.2.11 and wrapping with <Provider /> from "jotai" was all I had to do.

import { Provider } from 'jotai'

export default function Home() {
  return (
    <Provider>
      <InfiniteCanvas items={items} />
    </Provider>
  )
}