Why can I not read / write state (atom) values from functions directly?

[matthew-dean]

I've been evaluating different state libraries for React. I prefer Jotai over Valtio as it mimics useState instead of using side effects from Proxies. What's maddening, however, is that Jotai state cannot be used from utility functions, and I don't understand this. Why? Why not create a vanilla state library that has React effects (like Valtio does) instead of making React / components an implicit dependency? Why are these state values not readable / writeable? It's super-frustrating because there are lots of use cases for setting / reading state outside of React components, even within a React app. (Such as setting a global state for a set of utility functions.)

How hard would it be to add this functionality?

[dai-shi]

Thanks for opening a discussion. Jotai is based on React Context. A context is contextual and we only know where to access in a component. It's not accessible outside.

Now, from your description, it seems you are not using the capability of context and it's fine. Many use cases don't require context and you are not alone.

That's why Jotai provides the provider-less mode, which eases the non-context use cases. It also has unstable_createStore feature which allows you to access the store outside components. It's fairly stable but we would like to get more feedback before finalizing it.

Hope it helps.

[matthew-dean]

In order to get more feedback, should you not publish it somewhere? I don't see unstable_createStore documented in Jotai documentation.

Also, on Github, it looks like it's been unstable for about a year? Or since 2021 anyway? Any idea when you might stabilize it (the API at least, so it wouldn't have the unstable_ prefix? I think devs won't use it while it's called that).

[dai-shi]

I don't see unstable_createStore documented in Jotai documentation.

Yeah, documentation would be required to get more feedback.

But, I mean feedback like this #1422 is fine and welcome. We are interested in use cases.

Or since 2021 anyway?

https://github.com/pmndrs/jotai/releases/tag/v1.6.0
It's last Feb.

[dai-shi]

We are interested in use cases.

So, why do you want to read/write atoms outside components/hooks?

[dai-shi]

can't you reproduce the error in codesandbox?

[dai-shi]

btw, thanks for trying v2 API. we need feedback before finalizing it.

[gregor-mueller]

can't you reproduce the error in codesandbox?

Yes! After tinkering around, I found it to be almost working.

2 issues left.

Issue 1

The first issue that I see left right now is the typing of the setter function of an atom with initialiser that can also be undefined (will be never):

const selectedNumber = atom<number | undefined>(undefined)

const SomeThing(id: number) {
  const setSelected = useSetAtom(selectedNumber);

  return <button onClick={() => setSelected(id)}>Select {id}</button>
}

setSelected will be typed as never but actually work as a setter.

Link to affected line sandbox:
https://codesandbox.io/s/jotai-store-get-with-atomcallback-h8c9rf?file=/src/Counts.tsx:704-793

Issue 2

It is not possible to use an atomFamily with store.get(myFamilyAtom)

Link to affected line sandbox:
https://codesandbox.io/s/jotai-store-get-with-atomcallback-h8c9rf?file=/src/notifications.ts:308-377

[dai-shi]

Re: Issue 1

That happens when strictNullChecks: false in tsconfig.json. In general, strict: true is recommended, but a workaround would be this:

export const $selectedCountId = atom(undefined as number | undefined);

Re: Issue 2

It should be this:

  const count = jotaiStore.get($count(selectedCountId));

You might misunderstand atomFamily. It's just a Map:

// simplified code
const atomFamily = (initializeAtom) => {
  const cache = new Map();
  return (param) => {
    if (!cache.has(param)) {
      cache.set(param, initializeAtom(param));
    }
    return cache.get(param);
  };
};

ref: #1323 (reply in thread)

[gregor-mueller]

Re: Issue 1

That happens when strictNullChecks: false in tsconfig.json. In general, strict: true is recommended, but a workaround would be this:

export const $selectedCountId = atom(undefined as number | undefined);

I see, I thought, it was using strictNullChecks: true by default, as that's the config when you "create" a tsconfig.json in codesandbox.

👍

Re: Issue 2

It should be this:

  const count = jotaiStore.get($count(selectedCountId));

You might misunderstand atomFamily. It's just a Map:

ref: #1323 (reply in thread)

Gotcha! 👍

Thanks for responding in a quick and helpful manner!

[MOZGIII]

An example from the real world of how this can be useful:

I have a suite of helper functions (technically it is a service model, but we can say helper functions) that represents an action that spans over many atoms.

My app is a time tracker, and a good example is what happens when the user presses a stop button on the currently tracked entry.
The logic is something like this:

1. Call the trackerActions.stopAndRecord helper and pass the currentTime to it, which will internally do:
   1. Get the trackingState and taskName atom values
   2. Call the trackerActions.stop helper, which will internally do:
      1. Reset the trackingState and taskName atoms
   3. Construct a new record object with the values of taskName and trackingState atoms that we have captured captured before and the current time
   4. Call the recordsActions.upsert helper passing the record, which will internally do:
      1. Update the value of the records atom inserting or updating the record entry

The problem here is that the code that invokes the actions does not have anything to do with records (i.e. it is a timer stop button), but it would require importing the records action to proceed. In addition to that, it would be necessary to pass the setRecords to both the recordsActions.upsert (reasonable) and trackerActions.stopAndRecord (eh... ok?). My concern is what would happen if the helper is more complicated - passing one contextual-information carrting parameters is fine, two - a bit too much, but for each of the accessed atom would be painful for the ergonomics IMO.

---

I suggest jotai expose the underlying state store more explicitly when needed. I have two suggestions:

1. useAtomsStore

   // Declare a global atom
   const myAtom = atom(0);
   
   // Declare a global helper
   const myhelper = (atomsStore: ReturnType<typeof createStore>) => {
       myAtom.write(atomsStore.get, atomsStore.set, 1); // set the value to `1`
   }
   
   // In react
   const atomsStore = useAtomsStore(); // captures the context
   myHelper(atomsStore); // invoke the helper passing access to the store

2. useGetAtomStore

   // Declare a global atom
   const myAtom = atom(0);
   
   // Declare a global helper
   const myhelper = (getAtomStore: (atom: Atom<any>) => ReturnType<typeof createStore>) => {
       const storeForAParticularAtom = getAtomStore(myAtom);
       // getAtomStore(myOtherAtom) might return a different value here,
   	// and this opportunity to return different stores per atom is the key difference to the first suggestion 
       myAtom.write(storeForAParticularAtom.get, storeForAParticularAtom.set, 1); // set the value to `1`
   }
   
   // In react
   const getAtomStore = useGetAtomStore(); // captures the context
   myHelper(getAtomStore); // invoke the helper passing access to the store

In both cases we can capture the whatever store it currently utilized by react via a hook, so we don't loose the notion of the context-based state.
For global access, i.e. when the action truly has to originate from outside of react, it would be possible to create a global state (via createState) first, and then attach it to the tree via Provider so react uses it, and then pass it to the helpers directly when the callside does not have react contextual tree information.
Alternatively, the helper component can be inserted into the tree to expose the state information at a particular point via a global variable (let atomsStore; globally and atomsStore = useAtomsStore()) - but this is actually a mess because of concurrent rendering and remounts...

[dai-shi]

In case you don't follow, Jotai v2 API will expose store API. #1514

[MOZGIII]

I can see that, great!