something confused me about Provider initialValues and scope

[chj-damon]

I'm trying to seperate my project into several independent modules, and each module should be wrapped under the Provider and each module has its own atoms the sub component tree cares about.
the main structure would look like below:
App
|- ProviderRoot
|-|- ProviderA
|- |- |- SubTreeA
|- |- ProviderB
|- |- |- SubTreeB

// atom1/atom2/atom3 would only be used in SubTreeA
const atom1 = atom();
const atom2 = atom();
const atom3 = atom();

// atom4/atom5/atom6 would only be used in SubTreeB
const atom1 = atom();
const atom1 = atom();
const atom1 = atom();

// atom7 can be used in both SubTreeA and SubTreeB

the code is like this:

import { Provider, atom, useAtom } from 'jotai';

const atom1 = atom('');
const atom2 = atom('');
const atom3 = atom('');
const atom4 = atom('');
const atom5 = atom('');
const atom6 = atom('');
const atom7 = atom('');

export default function App() {
  return (
    <Provider>
      <ModuleA />
      <ModuleB />
    </Provider>
  );
}

function ModuleA() {
  return (
    <Provider>
      <SubTreeA />
    </Provider>
  );
}


function ModuleB() {
  return (
    <Provider>
      <SubTreeB />
    </Provider>
  );
}

function SubTreeA() {
  const [value1, setValue1] = useAtom(atom1);
  const [value2, setValue2] = useAtom(atom2);
  const [value3, setValue3] = useAtom(atom3);
  const [value7, setValue7] = useAtom(atom7); // this should be allowed
  const [value6, setValue6] = useAtom(atom6);// this should be forbidden

  return (
    <div>
    <div>value1: {value1}</div>
    <div>value2: {value2}</div>
    <div>value3: {value3}</div>
    <div>value7: {value7}</div>
    </div>
  );
}

function SubTreeB() {
  const [value4, setValue4] = useAtom(atom4);
  const [value5, setValue5] = useAtom(atom5);
  const [value6, setValue6] = useAtom(atom6);
  const [value7, setValue7] = useAtom(atom7); // this should be allowed
  const [value1, setValue1] = useAtom(atom1); // this should be forbidden
  return (
    <div>
    <div>value4: {value4}</div>
    <div>value5: {value5}</div>
    <div>value6: {value6}</div>
    <div>value7: {value7}</div>
    </div>
  );
}

I tried to give the different Provider different scope, but it doesn't work at all.

Is there any way that I can achieve my goal? my main target is to make each module unrelyable. ModuleA shouldn't care about anything in MouduleB, and vice versa. Those atoms that can be used in all the modules must be passed by the Provider above all the modules.

in my very first idea, I think scope can do this, which is what scope mean, it means boundary, gap. but as the doc says, scope is for library use. and I tried scope in my code, it doesn't prevent me from using an atom with different scope from the one in Provider:

<Provider scope={scope1}>
    <Component />
</Provider>

const Component = () => {
  const [value, setValue] = useAtom(atom1, scope2); // notice the scope is different
}

[Thisen]

@chj-damon. First of all, thanks for a good description of your problem.

scope allows for an atom to have different values in different "contexts" (Not React context). The reasoning for the note about library authors, is that scope was introduced to make sure you could create a library on top on jotai, without fearing a consumer would pollute your atom values, if you exposed those atoms aswell.

To solve your case, I'd do the following:

import { Provider, atom, useAtom } from 'jotai';

const atom1 = atom('');
const atom2 = atom('');
const atom3 = atom('');
const atom4 = atom('');
const atom5 = atom('');
const atom6 = atom('');
const atom7 = atom('');

const scopeA = Symbol("ModuleA");
const scopeB = Symbol("ModuleB");

export default function App() {
  return (
    <Provider> // Stays here for debugging purposes/inspection, but there's no functional need for it
      <ModuleA />
      <ModuleB />
    </Provider>
  );
}

function ModuleA() {
  return (
      <SubTreeA />
  );
}


function ModuleB() {
  return (
      <SubTreeB />
  );
}

function SubTreeA() {
  const [value1, setValue1] = useAtom(atom1, scopeA);
  const [value2, setValue2] = useAtom(atom2, scopeA);
  const [value3, setValue3] = useAtom(atom3, scopeA);
  const [value7, setValue7] = useAtom(atom7, scopeA);

  return (
    <div>
    <div>value1: {value1}</div>
    <div>value2: {value2}</div>
    <div>value3: {value3}</div>
    <div>value7: {value7}</div>
    </div>
  );
}

function SubTreeB() {
  const [value4, setValue4] = useAtom(atom4, scopeB);
  const [value5, setValue5] = useAtom(atom5, scopeB);
  const [value6, setValue6] = useAtom(atom6, scopeB);
  const [value7, setValue7] = useAtom(atom7, scopeB);
  return (
    <div>
    <div>value4: {value4}</div>
    <div>value5: {value5}</div>
    <div>value6: {value6}</div>
    <div>value7: {value7}</div>
    </div>
  );
}

A couple of things to note:

• I'm not using <Provider />, since there's no use for it, unless you want to use initialValues
• I can specify the scope as the second argument to useAtom
• There's no way to forbid an atom in a subtree

I hope this helps.

[chj-damon]

@Thisen thanks for your reply. I know I can do this without problem, but still, using atoms like this way has to command developers to be selfconscious that not to import atoms out of one module.
I want to know if there's a way that we can do this programatically. like forbidden usage of atoms out of your scope, or you can only use atoms out of your module because it's passed by the parenting Provider.

@dai-shi what is your suggestion?

[dai-shi]

  const [value1, setValue1] = useAtom(atom1); // this should be forbidden

When you say "forbidden", what should happen? Runtime error, compile error, or even not possible as ideas?

[chj-damon]

runtime error would be ok. it should report errors like: 'you can not access atom1 because you're not in the same scope'.

atoms can be used anywhere without constraints, It's convinient, but I don't thinks it's good for big projects, big projects always contain many modules which are developed by different groups, there should be some boundaries using atom.

[chj-damon]

I tried to practise DDD paradigm in projects, the main difference is that DDD projects are divided to different modules, each module has its own context, the communication between modules is not using something inside the module directly, but by interfaces or apis. moduleA should definitely a black box to moduleB, and vise versa.
I should separate all the atoms into different modules, and only can be used in this module.
But now since all the atoms can be imported and use directly, I cannot stop developers doing this way programmatically.

[dai-shi]

While it would be possible to raise a runtime error with a custom hook and a custom Provider, think it more like the atom config is an identifier or even a (global) variable.

Let's suppose you have a global variable in a big project and want to avoid directly accessing it, how would you? You wouldn't export the variable from the module. Likewise, you shouldn't export the atom config.

---

That said, there would be several (hacky) patterns to approach your needs. What I think is canonical for your use case is this:

const AtomNotInitialized = new Error() // or Symbol() or new Proxy(...) or just null
const atom1 = atom(AtomNotInitialized) // for module1
const atom2 = atom(AtomNotInitialized) // for module2

const Module1Provider = ({ children }) => (
  <Provider initialValues={[[atom1, '']]}>
    {children}
  </Provider>
)

const Module2Provider = ({ children }) => (
  <Provider initialValues={[[atom2, '']]}>
    {children}
  </Provider>
)

const useAtomSafely = (anAtom) => {
  const [value, setValue] = useAtom(anAtom)
  if (value === AtomNotInitialized) {
    throw AtomNotInitialized
  }
  return [value, setValue]
}

Think it like React.createContext(null) and check null for using useContext without Context.Provider. The way you put something in atom(something) behaves like React.createContext(something).

[chj-damon]

Isn't initialValues just for testing and SSR as the doc says so?

[dai-shi]

It's implemented from such requests, but it's a general feature not limited to specific use cases. Same applies to scope. I agree there's room for improvement in docs.

[chj-damon]

nice. I tried the initialValues and it works great in different Providers.

So now, all I need to do is put all the atoms I need in initialValues and use useAtomSafely to check if it's initialValue is not error or something like that.

[chj-damon]

I'll give it a try and if it works, I'll close this issue.

[chj-damon]

it works!! the full example is here: https://codesandbox.io/s/jotai-module-example-ls1c7

I give it a ModuleProvider so symbol don't have to be passed through useSafeAtom. Each module should be wrapped by ModuleProvider and give it an unique symbol.

@dai-shi any good suggestions that I can improve the develop experience?

[dai-shi]

@dai-shi any good suggestions that I can improve the develop experience?

Assuming you mean to contribute to the jotai project, this would be a good topic in advanced-recipes in docs.
We would need to discuss a bit more to make the doc as small and straightforward as possible.
It seems to me the ModuleContext is an additional feature and the basic pattern doesn't require it. Maybe, there are several patterns for this. I can think of the third pattern that comes with jotai provider scope.

[Thisen]

@chj-damon There's a different option aswell:

const ScopeGuardContext = createContext<Scope | null>(null)

function createScopedAtomHook(scope: Scope) {
  return (atom: Parameters<typeof useAtom>[0]) => {
    const currentScope = useContext(ScopeGuardContext)
    if (scope !== currentScope) {
      throw Error('Wrong scope')
    }
    return useAtom(atom)
  }
}

// ...

const useScopedAtom = createScopedAtomHook(myScope)

function SubTreeA(props) {
  return (
    <ScopeGuardContext.Provider value={myScope}>
      <MyComponent />
    </ScopeGuardContext.Provider>
  );
}

function MyComponent() {
  const [value] = useScopedAtom(atom1)
  // ...
}

createScopedAtomHook creates a useAtom hook, but it guards against not using the correct scope. There's a codesandbox for the pattern here:
https://codesandbox.io/s/next-js-with-custom-babel-config-forked-bp6qs?file=/pages/index.js

[chj-damon]

@Thisen but what about global atoms?

[Thisen]

@chj-damon Then you can just use useAtom

[chj-damon]

@Thisen I would not suggest that, because if so, developers can also use useAtom to get atoms inside some modules. I don't want to give more mental pressure. They can forget useAtom and only useSafeAtom is allowed.

[Thisen]

Im not sure I understand global atoms then.

[dai-shi]

hmm, converting an issue with comments to discussion make it hard to read the comments. I don't like this GitHub feature very much.

[chj-damon]

global atoms should be used the same way like other module atoms. developers don't have to recognize what atom is global or not. they treat them the same so the usage should be the same too.

[chj-damon]

const [globalValue] = useAtom(globalAtom);
const [moduleValue] = useAtom(moduleAtom); // which works, but it shouldn't.
const [moduleValue] = useScopeAtom(moduleAtom); // this should be fine.
const [globalValue] = useScopeAtom(globalAtom); // it means globalAtom is not in Provider initialValues

[Thisen]

I'm not 100% sure that I understand, but you could modify createScopedAtomHook to accept null for global atoms:

function createScopedAtomHook(scope: Scope | null) {
  return (atom: Parameters<typeof useAtom>[0]) => {
    const currentScope = useContext(ScopeGuardContext)
    if (scope !== null && scope !== currentScope) {
      throw Error('Wrong scope')
    }
    return useAtom(atom)
  }
}

const useGlobalAtom = createScopedAtomHook(null)

[chj-damon]

yes, that's what I mean. developers don't have to distinguish when to use useAtom, when to use createScopedAtomHook, only createScopedAtomHook is enough.

I think next step we can make an eslint plugin to help modify the wrong usage automatically.