Nested, side-effect-free atoms using scoped providers

[mayank99]

It took me a while to understand how to use Provider+store and get this to work but I wanted to share my implementation of useScopedAtom+ScopeProvider, and maybe get some feedback on whether this is how jotai is "supposed" to be used.

const _ScopeContext = React.createContext(createStore());

export function ScopeProvider({ children }) {
  return (
    <_ScopeContext.Provider value={React.useMemo(() => createStore(), [])}>
      {children}
    </_ScopeContext.Provider>
  );
}

export function useScopedAtom(someAtom) {
  const store = React.useContext(_ScopeContext);
  return useAtom(someAtom, { store });
}

🔗 Open in stackblitz

This essentially creates a new, standalone scope every time <ScopeProvider> is used. The implementation could be easily extended to create overlapping scopes that are completely independent of each other.

This is different from how Provider works out of the box — when a <Provider> is used, it overrides all state (global side effect). The default behavior of Provider makes it difficult to use jotai as an implementation detail within libraries, because it would conflict with application state.

[dai-shi]

Yes, it looks good.

Check out https://github.com/jotaijs/jotai-scope, createIsolation is a helper function which basically does the same thing as yours.

[mayank99]

Thanks for the response.

jotai-scope looks interesting for advanced cases, but I think my use case might be way simpler and not need all the code from jotai-scope. Would it make sense for a simpler version of it to be built into jotai core?

The docs for Provider says:

Multiple Providers can be used for multiple subtrees, and they can even be nested. This works just like React Context.

Reading this made me think it would behave similar to my ScopeProvider (or jotai-scope's createIsolation), but as you can see above, I had to completely sidestep Provider to achieve what I wanted.

[dai-shi]

jotai-scope has two features and createIsolation should be pretty small. If you don't like having unused code while developing, you should have your own version on your end. We don't plan to have it in core.

Hm, if the docs was misleading, can you propose an idea to mitigate it? Feel free to open a PR. ("This works just like React Context." is something I was hoping to make this behavior clear.)