useSetAtom, useAtomCallback and the missing useGetAtom

[ClementMindflow]

When manipulating atom from within a callback (without having to rerender when the atom change), we have currently several options:

First to write the atom imperatively, we can use useSetAtom to grab a stable callback that we'll use to set the atom imperatively from within the callback, or we could also use useCallbackAtom using the set parameter to set the atom.

Then to read an atom imperatively, we have to use the useCallbackAtom with the get parameter to get the atom.

My question is:
Why there is no symmetry between the two apis, put otherwise, why the useGetAtom hook does not exist ?

Or in the same direction, why useSetAtom exists if we can do the same with useAtomCallback ?

Thanks

[dai-shi]

useAtomValue is for read function, and useSetAtom is for write function. But, they aren't symmetric by nature, because the API design is to follow useState.

useAtomCallback exists for rather historical reason. Its implementation is pretty simple.

jotai/src/react/utils/useAtomCallback.ts

Lines 8 to 17 in f05d9ed

	export function useAtomCallback<Result, Args extends unknown[]>(
	callback: (get: Getter, set: Setter, ...arg: Args) => Result,
	options?: Options
	): (...args: Args) => Result {
	const anAtom = useMemo(
	() => atom(null, (get, set, ...args: Args) => callback(get, set, ...args)),
	[callback]
	)
	return useSetAtom(anAtom, options)
	}

useGetAtom will not follow React principles and theoretically breaks in concurrent rendering.
If you are interested, you can try useTransientAtom in jotai-game.

[ClementMindflow]

ok i get your point to match the useState api.

I understand that hook much better now...

So using setAtomImperatively from that code will in fact trigger a write operation on a "dummy" derived atom (the one in useAtomCallback), which will forward the write to the real atom (Which is a nonsense, i guess you'll agree)

const setAtomImperatively = useAtomCallback<MyAtom, MyAtom>(
    useCallback(
      (get, set, newValue) => {
        set(myAtom, newValue)
        return newValue
      },
      [myAtom]
    )
  )

And using getAtomImperatively from that code, will in fact read the value on the "dummy" derived atom which will "forward" the read operation to the "real" atom and return the value

const getAtomImperatively = useAtomCallback(
    useCallback(
      (get) => get(myAtom),
      [myAtom]
    )
  )

Two more questions:

• The usAtomCallback rely on the write function of derived atoms. I did not see in the doc that this function was able to return a value, what's the meaning of being able to return a value from the write function ?

• Why an implementation of useGetAtom similar to the second exemple here would not follow React principles and theoretically breaks in concurrent rendering ?

[dai-shi]

1: In v1, the return type was void. In v2, we can return anything, it will allow some usages (sometime requested). It's different from useState api.
2: It's reading a mutable store, which is fine in callbacks, but you can't use it in render (just like we can't read ref value').