fix(utils): make 'unwrap' update immediate after resolve

[organize]

Related Bug Reports or Discussions

Identical to #2790, but for unwrap
This regression is from the change here: #2695

Summary

When upgrading from 2.8.4 to 2.10.1, unwrap hangs in certain cases. I narrowed it down to atoms such as this one:

atomWithDefault((get) => get(unwrap(anAsyncAtom)))

Applying #2790 to unwrap fixes things.

Note that the recommended pattern for such atoms is to use two atoms:

const atomA = unwrap(anAsyncAtom);
const atomB = atomWithDefault((get) => get(atomA));

In this case, inlining atomA into atomWithDefault only works if unwrap's default fallback is used, meaning the following code will hang:

const atomB = atomWithDefault((get) => get(unwrap(anAsyncAtom, (prev) => prev ?? 'MAGIC_DEFAULT')));

Check List

• pnpm run prettier for formatting code and docs

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
jotai	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 11, 2024 11:09am

[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.

[github-actions]

Preview in LiveCodes

Latest commit: 8ac1645
Last updated: Nov 11, 2024 11:09am (UTC)

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

---

See documentations for usage instructions.

[dai-shi]

Nice catch. Unfortunately the second one is not technically solvable as I understand.

[dai-shi]

This doesn't work for certain cases if we want dynamic callbacks.
Let's educate users to define callbacks outside component or use useCallback.

[organize]

Alright, I can drop the commit. But could you elaborate just so I understand, what would be the use case? And is it something you would prefer to support over the one in my example above?

Do you mean something like this:

atomWithDefault((get) => get(unwrap(anAsyncAtom, (prev) => prev ?? getSomeDefaultValueThatMayChange())))

Thinking further, this definitely needs to be documented as a breaking change - a Jotai eslint plugin could be useful to disallow inline callbacks here if that's what you mean 🤔

[dai-shi]

Not a specific use case in mind, but the function can be anything and prev => prev ?? DEFAULT is only one use case.

It's not a change as I see it. Not only unwrap, but also useAtomCallback always expect stable selectors. It's kind of surprising inline callbacks worked in previous versions as it's not intended.

That said, because atomWithDefault((get) => get(unwrap(anAsyncAtom, (prev) => prev ?? DEFAULT))) worked previously by chance, it's better to document it for explicitly. Would you like to open another PR for doc improvement?

My recommendation is to separate it into two atoms:

const atomA = unwrap(anAsyncAtom, (prev) => prev ?? getSomeDefaultValueThatMayChange());
const atomB = atomWithDefault((get) => get(atomA));

[organize]

That's fair, thank you. I can make another PR to update the documentation. I'll drop the commit now.

[dai-shi]

The code diff looks good to me.
Please check CI errors and update the PR description.

[dai-shi]

LGTM. Thanks for your contribution.
Will merge it next week.