jotai-derive/jotai-eager does not work as of [email protected] -- a stable mechanism for storing a promise's status, orthogonal to React

[iwoplaza]

Bug Description

Hi! I was cleaning up jotai-derive, and bumping dev dependencies, when I noticed that the test cases were failing for new versions of jotai (e.g. 2.10.x), while they worked for 2.9.0. After looking through repositories using jotai-derive nowadays, they're using the unstable_promiseStatus flag in useAtomValue.

Related discussions and pulls: #3026, #2848

jotai-derive was relying on an internal behavior of Jotai async atoms, mainly the attached statuses. Without them, microsuspensions cannot be avoided as easily. I believe Jotai attaching statuses was meant as a polyfill for React 19's use behavior, and in the latest versions of Jotai, statuses are only attached to Promises that are values of atoms that directly touch useAtomValue, not transitively. This also means that jotai-derive cannot work using the vanilla store.set, store.get, and store.sub APIs. Since microsuspensions seems to still be an ongoing problem for users, I would love for us to find a way forward 🌊🚣‍♀️

My proposal would be to:

• Make Jotai store it's own set of statuses for each Promise, separate from the current use polyfill, in a way that does not conflict with React. (Maybe a WeakMap of Promise->Status that libraries like jotai-derive can have access to and can rely on).
• Store the status of each async Promise handled in the store, not only for leaf atoms passed into useAtomValue.

I look forward to your feedback 🙇

Reproduction Link

https://github.com/jotaijs/jotai-derive/actions/runs/15111812681/job/42472813075?pr=5

[dai-shi]

btw, let's add jotai-eager in https://github.com/jotaijs/jotai-ecosystem-ci.

[dai-shi]

Does derive depend on promise status? Or only eagerAtom?

[iwoplaza]

soon, soonAll, derive and eagerAtom depend on the promise status (so all current APIs). I could attach my own promise statuses in jotai-eager, and that would solve most of the micro-suspensions, but a lot of unnecessary recomputations/microsuspensions could be spared if the status tracking was done inside of the store itself.

With jotai-derive tracking:

const userAtom = atom(async () => ...);
const uppercaseNameAtom = derive([userAtom], (user) => user.name.toUppercase());
const labelAtom = derive([userAtom, uppercaseNameAtom], (user, name) => {
  return `${name} (#${user.id})`;
});

const store = createStore();
const user = await store.get(userAtom);
// ...

// We have to await/suspend, because from the perspective of `labelAtom`, `userAtom` holds a
// Promise that has no status yet (because it's the first time it's handled by `jotai-derive` APIs)
const label = await store.get(labelAtom); // => Promise<string>

With store tracking:

const userAtom = atom(async () => ...);
const uppercaseNameAtom = derive([userAtom], (user) => user.name.toUppercase());
const labelAtom = derive([userAtom, uppercaseNameAtom], (user, name) => {
  return `${name} (#${user.id})`;
});

const store = createStore();
const user = await store.get(userAtom);
// ...

const label = store.get(labelAtom); // => string

[dai-shi]

Oh, I see soon depends on it too.

It's our design decision to have "attaching promise status" logic outside of Jotai core.
So, attaching it in jotai-derive/eager is expected by design. I don't think you need "own" status. Just do the same as use as that's the idea React team pushes.

Let me know if you need help.

[iwoplaza]

I was leaning towards tracking my own status as opposed to overriding properties on the Promise to not interfere with React internals. If React ever changes the meaning of those properties, and jotai-derive always overrides them, then the resulting bugs could be very hard to debug.

I was thinking of doing something like the unwrap internal cache. What do you think?

[dai-shi]

Yeah, it's your call. Yes, WeakMaps should be good in that case.