Unwrapped Atom Always Returns undefined on First Read After v2.10 Update

[ics-matsumoto]

After upgrading to v2.10, the first read of an unwrapped atom always fails (returns fallback or undefined), even if the target atom has already been fulfilled. Below is a minimal reproduction example:

const asyncValueAtom = atom(async () => {
  await 0;
  return "async value";
});

// check if async value already fetched
const checkValueAtom = atom(undefined, (get) => {
  const value = get(unwrap(asyncValueAtom));
  console.log(value ? "value is ready" : "value is not ready");
});

function App() {
  const value = useAtomValue(asyncValueAtom);
  const check = useSetAtom(checkValueAtom);
  return (
    <>
      {value}
      <button onClick={check}></button>
    </>
  );
}

From the code and test changes, this seems to be an intentional change, not a bug:
e777f46#diff-27dc4fc1ccc94f5995d614166f24d0646197062957c7cca39300f48b60e16af1R136

However, I couldn't find any explanation for this change. This behavior can sometimes cause issues when using unwrap in the set function of atoms. Is this behavior a deliberate and desirable change, or was it an unavoidable compromise?

[dai-shi]

@dmaskasky Can you look into it please?

[dmaskasky]

Fix: #2880
Note: it depends on the newly proposed atom.unstable_onInit api.

[dai-shi]

Note: it depends on the newly proposed atom.unstable_onInit api.

That's an interesting idea. I think we can do something better. Let's spend time on it.

[dai-shi]

From the code and test changes, this seems to be an intentional change, not a bug

Yeah, it's intentional.

However, I couldn't find any explanation for this change.

I'm sorry. It's not described well. The rationale is that our store implementation shouldn't deal with promises. It's the core principle of Jotai v2 actually.

unwrap doesn't do a magic now. It takes one tick to resolve a promise. So you should basically prepare for undefined even if it's Promise.resolve(0).

I wonder if this works for your case.

const checkValueAtom = atom(undefined, async (get) => {
  const value = await get(asyncValueAtom);
  console.log(value ? "value is ready" : "value is not ready");
});

Is this behavior a deliberate and desirable change, or was it an unavoidable compromise?

I don't plan to change the store api as it's basically a conceptual fix.
A workaround fix in unwrap is acceptable and @dmaskasky might have a good idea. It may take some more time.
Stay tuned, but there's no guarantee if we can make it.

[dmaskasky]

I might be able to offer a third-party fix at some point if there is a valid use-case and it doesn't cause too much confusion.

[ics-matsumoto]

Thank you for the response. My original motivation for this question was to inspect the current atom data to reduce the need for async functions. I think this approach is not too unusual.

But as @dai-shi mentioned, allowing peeking into a Promise’s internal state would feel a bit magical and go against the core principles of Jotai, which I now understand.

I sometimes try to implement all logic within atoms, but perhaps this is something that should be addressed outside of atoms instead.