investigate side-effect regression

[dmaskasky]

Related Bug Reports or Discussions

#3164

Fixes #

Summary

• add failing test
• revert f5d843c

I don't think we should merge this PR. I don't think Jotai should support side-effects in atom read.

The use-case which spawned this investigation was with

function atomShallowEqual<T>(fn: (get: Getter) => T): Atom<T> {
  const previousValueAtom = atom<T | void>();
  return atom((get) => {
    const jotaiStore = getDefaultStore();
    const oldValue = jotaiStore.get(previousValueAtom);
    const newValue = fn(get);
    jotaiStore.set(previousValueAtom, newValue);
    if (!oldValue) {
      return newValue;
    }
    return shallowEquals(newValue, oldValue) ? oldValue : newValue;
  });
}

I think there could be a better pattern for above. I haven't found a pattern that supports side-effects in read.

Check List

• pnpm run fix for formatting and linting code and docs

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
jotai	Ready	Preview	Comment	Oct 8, 2025 10:43pm

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[pkg-pr-new]

More templates

• hacker_news
• hello
• mega-form
• starter
• text_length
• todos
• todos_with_atomFamily

npm i https://pkg.pr.new/jotai@3165

commit: f5edd30

[github-actions]

Preview in LiveCodes

Latest commit: f5edd30
Last updated: Oct 8, 2025 10:43pm (UTC)

Playground	Link
React demo	https://livecodes.io?x=id/GCEZ9WQ3E

---

See documentations for usage instructions.

[dmaskasky]

/ecosystem-ci run

[github-actions]

Ecosystem CI Output

---- Jotai Ecosystem CI Results ----
{
  "bunshi": "PASS",
  "jotai-devtools": "PASS",
  "jotai-effect": "FAIL",
  "jotai-scope": "PASS",
  "waku-jotai": "PASS"
}

[dmaskasky]

"jotai-effect": "FAIL",

I expected this.

[dai-shi]

(I'll have a look later.)
(Sorry for the delay, not on it yet.)

[dai-shi]

Sorry for the delay. I agree. This shouldn't be merged.

[dai-shi]

We don't need to support this.
If we can't support this, we should probably warn it (dev only) if we can detect it.

[dai-shi]

The use-case which spawned this investigation was with

function atomShallowEqual<T>(fn: (get: Getter) => T): Atom<T> {
  const previousValueAtom = atom<T | void>();
  return atom((get) => {
    const jotaiStore = getDefaultStore();
    const oldValue = jotaiStore.get(previousValueAtom);
    const newValue = fn(get);
    jotaiStore.set(previousValueAtom, newValue);
    if (!oldValue) {
      return newValue;
    }
    return shallowEquals(newValue, oldValue) ? oldValue : newValue;
  });
}

My suggestion is something like this:

function atomShallowEqual(initialValue) {
  const valueAtom = atom(initialValue);
  return atom(
    (get) => get(valueAtom),
    (get, set, newValue) => {
      const oldValue = get(valueAtom);
      if (!shallowEqual(oldValue, newValue)) {
        set(valueAtom, newValue);
      }
    }
  );
}

So, the challenge is how we can do with fn: (get: Getter) => T.
If the requirement is only about shallowEqual, and if we only need to support one jotai store, we could simply use a scope variable.

function atomShallowEqual(fn) {
  let lastValue;
  return atom((get) => {
    const value = fn(get);
    if (!shallowEqual(lastValue, value)) {
      lastValue = value;
    }
    return lastValue;
  });
}

It still violates purity, but it feels like a better hack.