Is there a substantual difference between these 2 pattern with <Provider> ??

[tresorama]

Hey, i'm testing using jotai Provider in a situation where i have:

• a button that create Counter (multiple Counter are allowed)
• each Counter has its state atom
• when a new counter it's created the atom for that counter must be initialized with a random initial value

So i need to use the Provider for sure.
Looking at docs, I was able to use 2 distinct patterns for doing that, I did, and both are working.

So my question is: Is threre a difference between the two or they are equivalent??

You can view the code in this codesandbox.

Pattern 1

with <Provider> pattern 1 (<AtomsHydrator>)
https://codesandbox.io/p/devbox/jotai--providers-jlyts5?file=%2Fsrc%2Fcomponents%2Fviews%2Fjotai%2Freusable-store-1%2Findex.tsx

Pattern 2

with <Provider> pattern 2 (createStore())
https://codesandbox.io/p/devbox/jotai--providers-jlyts5?file=%2Fsrc%2Fcomponents%2Fviews%2Fjotai%2Freusable-store-2%2Findex.tsx

---

Edit 1:
Added direct link to specific code of the sandbox to every pattern

Edit 2:
Added other Pattern, emerged in the conversation.
The original question has only Pattern 1 and 2.

---

Pattern 3

without Provider, with atom instances saved in useState
https://codesandbox.io/p/devbox/jotai--providers-jlyts5?file=%2Fsrc%2Fcomponents%2Fviews%2Fjotai%2Freusable-store-3%2Findex.tsx

Pattern 4

without Provider, with atomFamily and atom instances saved in useState
https://codesandbox.io/p/devbox/jotai--providers-jlyts5?file=%2Fsrc%2Fcomponents%2Fviews%2Fjotai%2Freusable-store-4%2Findex.tsx

Pattern 5

without Provider, with jotai-scope
https://codesandbox.io/p/devbox/jotai--providers-jlyts5?file=%2Fsrc%2Fcomponents%2Fviews%2Fjotai%2Freusable-store-5%2Findex.tsx

[rothsandro]

Do you need separate stores? Instead of using the same atom with multiple stores I would rather create separate atoms for each counter and use just one store.

You can use an atom family or atoms in atoms. The random initial value can then be computed when creating the atom.

[tresorama]

Thanks for the reply.
It made me thinking about other things...

Do you need separate stores?

No, I'm using this pattern because of the Provider.
My goal is to have multiple instances of the same atom definition.

Instead of using the same atom with multiple stores I would rather create separate atoms for each counter and use just one store

If i have :

1. a global atom (like currentPageAtom with global data, a singleton) that need to be accessed across all app
2. and some JotaiProvider in some subtrees (and each JotaiProvider initialize a new store with createStore())
   Child components of the point 2, can access the atom of point 1 ???

You can use an atom family or atoms in atoms.

Atoms family is like havong multiple duplicates of an atom, each one with a unique identifier ("counterAtom#1", "counterAtom#2"...) and all of them have the "state" saved in the same jotai store ??

[rothsandro]

Child components of the point 2, can access the atom of point 1 ???

Theoretically it's possible but it introduces some overhead. You can define a global store and then pass this store to your global Jotai Provider (for point 1) and then also pass the store to the atom hooks for point 2 (e.g. useAtom(currentPageAtom, { store: myGlobalStore })). But if you ever forget to pass the store in point 2 you will end up with the wrong state. I wouldn't recommend working with multiple store for this scenario.

[...] all of them have the "state" saved in the same jotai store?

Yes, each counter get its own atom config instance (but with the same "blueprint", i.e. they all work the same way) and the state is stored in the same store. This way you can access currentPageAtom from everywhere and you don't have to pass the store separately.

You just need a way to keep the atom config of each counter somewhere. Atom Family is just one way to do it. As you already have a list of counters you can also store the atom config there as part of the counters object (next to the id).

Edit: here's how this could look like: https://codesandbox.io/p/devbox/jotai--providers-forked-lkryfk

[dmaskasky]

Another solution is to use jotai-scope

https://jotai.org/docs/extensions/scope

[tresorama]

@rothsandro

I wouldn't recommend working with multiple store for this scenario.

I added a global atom to every pattern in the codesandbox and now i see clearly that Provider "way" has drawabacks, meaning that the Provider subtree cannot access "updates" of atoms served by root Provider (the provider that user land do not explicitly use).
But with your example (included in the sandbox as Pattern 3) this problem is not present, and also with atomFamily (Pattern 4) and jotai-scope (Pattern 5)

@dmaskasky
Thanks for pointing me at jotai-scope, it's great because doesn't preclude access to global atoms from ScopeProvider subtrees.
The only downside is that it doesn't provide an easy way to declare dynamic initial state for the atom.

[rothsandro]

The only downside is that it doesn't provide an easy way to declare dynamic initial state for the atom.

With jotai-scope you don't need separate atom configs anymore but you can reuse the same global atom for all counters and then use your <AtomsHydrator /> component (as child of ScopeProvider) to set a random initial value for each counter.

If the initial value can be created outside of React (i.e. you don't need any props, context value, etc) you can also use atomWithLazy(() => ({ count: random(0, 200) )) instead of hydrating atoms.