Jotai for libraries

As a library author, I want to make sure the values of the atoms my library relies upon are only updated in the jotai.Providers I control and not the ones, the users of my library might add to the tree for their own purposes.

I believe we need some API in jotai to support it. The initial discussion happened here

[youknowriad]

Hey there!

First, thank you for jotai, it’s an amazing library and learned a lot from it.

For context, I work on the WordPress block editor and we have a data layer package called @wordpress/data that relies mostly on Redux stores with some specifics. We faced performance issues while rendering a lot of components and we started exploring alternatives. Right now we are considering a solution based on atoms like Recoil and Jotai.

I’d have loved to be able to use Jotai directly, unfortunately, the specifics of the data module don’t allow that. We need a library that is fundamentally React agnostic, and we also need something that can work in multiple registries/scopes (and that’s why I’m commenting here).

I’m not sure if it’s any helpful but I wanted to share this very experimental PR I’m currently working on https://github.com/WordPress/gutenberg/pull/26866 which creates that (a framework and scope agnostic alternative to Recoil and Jotai). My approach there was to use “registries” (though I like the proposed name here “scope”).

[dai-shi]

A little bit of extra thing to always keep in mind that you need to set scope for each atom you are creating but most of the libraries

@vovacodes I’m expecting a lib author to create its own wrapper, something like this:

import { atom as atomOrig } from 'jotai'

const myScope = Symbol()
export atom = (read, write) => {
  const anAtom = atomOrig(read, write)
  anAtom.scope = myScope
  return anAtom
}

I think Jotai would benefit from having a vanilla bundle like Zustand.

@mdingena @youknowriad Actually, it might be a good idea to keep the core code cleaner. I’m still working on refactoring core. However, the vanilla bundle might not be very useful as is, because it would be an unusual api to support React Concurrent Mode.

(tbh, I’m not so keen to provide framework-agnostic version of atom state management, just because there are already many: mobx, reatom or naive observables)