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.

[hi-ogasawara]

@dai-shi @dmaskasky
Thank you for your comment!
I now have a better understanding.
However, it is a movement that is read to the first level and I don't understand that. I have made a new comment and would appreciate if you could take a look at it.

#2789 (comment)

[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((get) => get(b))
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.

[hi-ogasawara]

@dai-shi

A fetchAtom is read even though it is not used by the component.
I would like to know what I do not understand about this.

I was asking the question because all the dependencies were not updated in pattern 3 and I wanted to confirm my understanding of this.
Comment helped me understand and this is ok.
Thank you!

That sounds interesting. It can be a bug. Would you like to dig into it?
I think our first step is to write a failing test.

I am worried because I am new to this kind of activity.
But I want to give it a try, so I will try to write a test that will fail first.
Just to confirm, am I correct in understanding that you want to modify it to track and update dependencies?

[dai-shi]

Just to confirm, am I correct in understanding that you want to modify it to track and update dependencies?

Good point. The first one (memory leak) is not very critical, but the second one (not updating) can be important. If we were to fix only the second one, we can continue our current design (eager updating), but for the first one we many need lazy updating. I'm not very sure.

Maybe @dmaskasky can elaborate.

But I want to give it a try, so I will try to write a test that will fail first.

Take it easy. I can't guarantee if we can merge what you make at this point anyway.
The test with store api is better if possible.

See this as an example:

jotai/tests/vanilla/dependency.test.tsx

Lines 338 to 348 in 5e2bcc0

	it('can read sync derived atom in write without initializing', () => {
	const store = createStore()
	const a = atom(0)
	const b = atom((get) => get(a) + 1)
	const c = atom(null, (get, set) => set(a, get(b)))
	store.set(c)
	expect(store.get(a)).toBe(1)
	store.set(c)
	// note: this is why write get needs to update deps
	expect(store.get(a)).toBe(2)
	})

[dmaskasky]

Hi Hiroki,

I'd be happy to review a PR, feel free to add me if you decide to write one.

I think the missing functionality can be summed up as we want get in the write function to act as a deep peek. Reading atoms with get should not cause dependencies or their dependents to mount and the dependency graph should not be altered.

I think it would be good to work on "deep peek" next.

[dmaskasky]

Update: Here's a PR that has a test for this case and an early prototype of deep peek.
#2845

I worry though, because I realize if dependencies are not updated then it is necessary to recompute each time. Is this correct?

[dai-shi]

We will take #2849.

The memory leak I mentioned turned out to be an expected behavior with the current implementation.