If the dependency of the atom being get by useAtomCallBack(write-only atom) is changed, that atom will be read.

[hi-ogasawara]

Bug Description

Atoms not used in components are read

I thought it would not read for the following reasons, but it does

• write-only atom “get” does not track dependencies
• fetchAtom is not used in the component (“useAtomValue”　or "useAtom" is not set)

Even though read-only atom (fetchAtom) is used only with useAtomCallBack When “userConfigTime” is used in a component, fetchAtom is read.

1. Update data with the “CallBackPage:OpenAndUpdate” button.
2. “Dependency: Update” button Update dependencies.
3. Console log shows fetchAtom:read (fetchAtom is being read).
   *The same event occurs with write-only atom instead of useAtomCallBack To confirm, uncomment the write-only pattern.

NOTE

If you change a dependency without ever updating it, fetchAtom is not read.

1. Reload.
2. “Dependency: Update” button Update dependencies.
3. The console log does not show fetchAtom:read (fetchAtom is not read).
   *The same event occurs with write-only atom instead of useAtomCallBack To confirm, uncomment the write-only pattern.

Instead of userConfigTime in fetchAtom Get (uncomment) wrapUserConfigTime. If the dependency is updated after this, wrapUserConfigTime is read instead of fetchAtom.

1. Comment out return get(userConfigTime) and uncomment return get(wrapUserConfigTime) in fetchAtom.
2. Update data with the “CallBackPage:OpenAndUpdate” button.
3. “Dependency: Update” button Update dependencies.
4. wrapUserConfigTime:read appears in console log (read to wrapUserConfigTime).
   *The same event occurs with write-only atom instead of useAtomCallBack To confirm, uncomment the write-only pattern.

Inference from the above

It is likely that atom has been read in the following conditions.

• write-only atom is used at least once.
• The atom that is a dependency within the atom that the write-only atom is getting is used in the component.
  (userConfigTime in fetchAtom in useTestAPI is used by the component.)
  (In this case, dependencies are only tracked up to the first level.)

Reproduction Link

https://github.com/hi-ogasawara/AtomCallBackTest.git

[dai-shi]

jotai/src/react/utils/useAtomCallback.ts

Line 16 in 62c4892

return useSetAtom(anAtom, options)

useAtomCallback shouldn't subscribe to an atom.
Can you try to create a minimal reproduction with StackBlitz?

[hi-ogasawara]

@dai-shi
Minimal reproduction was done with StackBlitz.
You can check it out at the link below.
https://stackblitz.com/edit/vitejs-vite-ydy9nj?file=src%2FApp.tsx

[dai-shi]

Interesting... I'm not sure how it's happening.

@dmaskasky When you have a chance, can you take a look?

[dai-shi]

#2789 (comment) is great explanation.

So, it was partly my misunderstanding, and in the provided case, we need to track dependencies. This can be said as the limitation in the current implementation, but we don't have any other solutions at the moment.

[dmaskasky]

Your understanding of the behavior of useAtomCallback and the internal workings of Jotai is largely correct, but the distinction you’ve noted between atom.read and atom.write deserves some clarification, particularly regarding dependency tracking within the context of write operations.

Here’s a more detailed explanation:

---

Key Observations

1. atom.read Behavior:

   • The get function in atom.read is designed to track dependencies. When you call get(atom) within an atom.read function, Jotai automatically adds the accessed atom to the dependency list of the current atom. This enables reactivity: changes to any of the dependencies trigger a re-evaluation of the atom.

2. atom.write Behavior:

   • The get function in atom.write does not directly add dependencies to the root atom (the one being written). This is intentional because atom.write operations are generally not reactive and are used for imperative updates.
   • However, any atoms accessed within the dependency subtrees during the evaluation of atom.write will add dependencies to their own internal state if the same logic for atom.read is reused internally.

---

Why Dependencies Are Added in Subtrees

The key lies in the shared mechanism used internally to evaluate dependencies. When readAtomState is called, regardless of whether it originates from a read or write operation, it updates the dependency tracking for the atom being accessed.

• atom.write doesn't track dependencies at the root level:
  This prevents unintended reactivity when an atom is imperatively updated.

• Dependencies are still added in subtrees:
  If get is called on an atom that itself has dependencies, those dependencies are tracked normally. This is why dependencies can still be observed propagating through the tree during a write operation.

---

Example atom dependency tree

Consider the following code:

const store = createStore()
const a = atom(null, (get, set) => {
  set(a, get(b))
})
let bReadCount = 0
const b = atom((get) => {
  ++bReadCount
  return get(a) + 1
})
const c = atom(0)
store.sub(c, () => {})
store.set(a)
expect(bReadCount).toBe(1)
store.set(c, 2)
expect(bReadCount).toBe(1) // fails: received 2

The dependency tree accessed by A.write's getter is as follows:

A
│
└── B
    └── C

If A (a write atom) accesses B, and B accesses C:

1. During a write operation on A:

   • A does not track B as dependencies at the root level.
   • B will still track C as a dependency because readAtomState for C is invoked during the evaluation of B.

2. Reactive Re-Evaluation:

   • Updates to C will trigger a re-evaluation of B.
   • Updates to B or C do not trigger a re-evaluation of A.

---

Summary of Behavior

• atom.write:
  • Root atom: Dependencies are not added to the atom being written.
  • Subtree atoms: Dependencies are added normally if accessed during the write operation.

---

Why is this behavior necessary?

Let us again consider the sample code from earlier:

const store = createStore()
const a = atom(null, (get, set) => {
  set(a, get(b))
})
const b = atom((get) => {
  return get(a) + 1
})
const c = atom(0)
store.sub(c, () => {})
store.set(a)
expect(store.get(c)).toBe(1)
store.set(a)
expect(store.get(c)).toBe(2) // otherwise would fail if write's get acted as peek

If write's get does not update b's dependencies, then b would never recalculate when a is updated, and the last line in the code above would fail.

[hi-ogasawara]

@dmaskasky
cc @dai-shi

Thanks for the explanation!
I am a little concerned about a few things in the source code.
Details are as follows.

I am thinking of the following, is my perception correct?

• It is a write-only atom.
• Basically, it cannot be set for atom itself..

const a = atom(null, (get, set) => {
  set(a, get(b))
})

Is it likely that I need to get c in order to depend on b?

const b = atom((get) => {
  return get(a) + 1
})

If modified, it would look like this.
Is the changed source code correct?
*Execution results not verified.

const store = createStore()
const a = atom(null, (get, set) => {
  set(c, get(b))
})
const b = atom((get) => {
  return get(c) + 1
})
const c = atom(0)
store.sub(c, () => {})
store.set(a)
expect(store.get(c)).toBe(1)
store.set(a)
expect(store.get(c)).toBe(2)

[dmaskasky]

Oops. A few corrections...

The code is supposed to be:

const store = createStore()
const a = atom(0)
const b = atom((get) => get(a) + 1)
const c = atom((get) => get(a))
const w = atom(null, (get, set) => set(a, get(b)))
store.sub(c, () => {})
store.set(w)
expect(store.get(c)).toBe(1)
store.set(w)
expect(store.get(c)).toBe(2)

[hi-ogasawara]

@dmaskasky
Thank you very much!

[hi-ogasawara]

@dai-shi
cc @dmaskasky
I would like to know why the following phenomena are occurring.

If it is not used in a component, I would expect it to not be read if the dependency is changed.
But it is read to the first level.

fetch atom being read

1. Update data with the “CallBackPage:OpenAndUpdate” button.
2. “Dependency: Update” button Update dependencies.
3. Console log shows fetchAtom:read (fetchAtom is being read).
   *The same event occurs with write-only atom instead of useAtomCallBack To confirm, uncomment the write-only pattern.

wrapUserConfigTime is read instead of fetchAtom.

1. Comment out return get(userConfigTime) and uncomment return get(wrapUserConfigTime) in fetchAtom.
2. Update data with the “CallBackPage:OpenAndUpdate” button.
3. “Dependency: Update” button Update dependencies.
4. wrapUserConfigTime:read appears in console log (read to wrapUserConfigTime).
   *The same event occurs with write-only atom instead of useAtomCallBack To confirm, uncomment the write-only pattern.