Patterns for updating "sync" atoms that depend on async atoms like in V1

[Pinpickle]

In my current project, (still on 1.X), I use this pattern where a "sync" atom depends on an async atom. It's not actually sync but once the async atom first loads it effectively is. Something like this:

const syncCountAtom = atom(0);
const asyncAddAtom = atom(Promise.resolve(1));
const countAtom = atom(
 (get) => {
    return get(asyncAddAtom) + get(syncCountAtom);
  },
  (get, set) => {
    set(syncCountAtom, (c) => c + 1);
  }
);

Once countAtom finishes suspending for the first time, I can set it and not worry about it ever suspending again.

In V2, there's no special suspense inside atoms, so async atoms are just promises. This means that my countAtom has to have an async getter. Whenever I set it, it suspends (for a very small amount of time).

In some cases (not all), it's trivial to wrap in a React 18 startTransition, but I'm not sure what kind of guarantees I get when opting into concurrent features like that.

Here's a codesandbox showing what I mean:

https://codesandbox.io/s/sync-and-async-atom-setting-n4g46r?file=/src/App.tsx

Are there any patterns for getting the old behaviour back?

[dai-shi]

Thanks for opening the discussion.
I've considered a lot when introducing v2 breaking changes. Unfortunately, there are no silver bullets.
There are three ways to work around your case.

Use unstable_unwrap

This is essentially to mitigate v1 usage. It's not one-to-one, but you can get sync atom from an async atom.
Hopefully, we'll soon remove unstable_ prefix and document it.

Jotai store follows React convention for promises.

It has status property and value property on fulfillment.

jotai/src/vanilla/store.ts

Lines 38 to 43 in 2188d75

	type PromiseMeta<T> = {
	status?: 'pending' | 'fulfilled' | 'rejected'
	value?: T
	reason?: AnyError
	orig?: PromiseLike<T>
	}

We don't know if we consider it a public API. It depends on how entire React community goes. For now, we should consider it an internal API.
Here's the example: https://codesandbox.io/s/sync-and-async-atom-setting-forked-p8q9zp

useAtom's delay option

This is not documented yet as we have been unsure about the use case.
But, it's there for such cases like yours.

jotai/src/react/useAtomValue.ts

Lines 44 to 47 in 2188d75

	type Options = {
	store?: Store
	delay?: number
	}

Here's the example: https://codesandbox.io/s/sync-and-async-atom-setting-forked-lsgwlz

[Pinpickle]

@dai-shi that's exactly the concern with migrating. If I were writing a project today from scratch, I'd want the "sync-in-async" style.

Not because I find it intuitive or anything... I would personally prefer to use async/await if the semantics worked in the context of a reactive application.

The only motivating factor for me is merging sync and async state together. Like the countAtom example I gave, I want to update syncCountAtom without countAtom returning a promise (and needing to wait for a microtask and suspending the component).

const syncCountAtom = atom(0);
const asyncAddAtom = atom(Promise.resolve(1));
const countAtom = atom(
 (get) => {
    return get(asyncAddAtom) + get(syncCountAtom);
  },
  (get, set) => {
    set(syncCountAtom, (c) => c + 1);
  }
);

This would be the same as doing the computation inside the component.

const asyncAddAtom = atom(Promise.resolve(1));
const syncCountAtom = atom(0);

const MyComponent = () => {
  const asyncAdd = useAtomValue(asyncAddAtom);
  const syncCount = useAtomValue(syncCountAtom);
  const count = syncCount + asyncAdd;
  // etc...
}

The only way for this to happen (as far as I'm aware) is if countAtom does not return a promise.

To me, suspense seems the most ergonomic way to do this. unstable_unwrap would definitely work, but it requires more boilerplate:

const syncCountAtom = atom(0);
const asyncAddAtom = atom(Promise.resolve(1));
const countAtom = atom(
 (get) => {
    const addValue = unstable_unwrap(get(asyncAddAtom));
    if (addValue == null) {
      // wait forever
      return new Promise(() => {});
      // alternatively: return null;
    }

    return addValue + get(syncCountAtom);
  },
  (get, set) => {
    set(syncCountAtom, (c) => c + 1);
  }
);

[dai-shi]

unstable_unwrap would definitely work, but it requires more boilerplate:

I'm not sure if I understand your last example. You want to make countAtom not suspend at all, right?
How does this feel?

const syncCountAtom = atom(0);
const asyncAddAtom = atom(Promise.resolve(1));
const defaultAddValue = (prev) => prev ?? 0;
const countAtom = atom(
 (get) => {
    const addValue = get(unstable_unwrap(asyncAddAtom, defaultAddValue));
    return addValue + get(syncCountAtom);
  },
  (get, set) => {
    set(syncCountAtom, (c) => c + 1);
  }
);

OR

const syncCountAtom = atom(0);
const asyncAddAtom = atom(Promise.resolve(1));
const unwrappedAsyncAddAtom = unstable_unwrap(asyncAddAtom, (prev) => prev ?? 0);
const countAtom = atom(
 (get) => {
    return get(unwrappedAsyncAddAtom) + get(syncCountAtom);
  },
  (get, set) => {
    set(syncCountAtom, (c) => c + 1);
  }
);

If you want to initially suspend with countAtom, it's different.

[Pinpickle]

Oops I was completely misunderstanding how unstable_unwrap works - I've never actually used it. Thanks for correcting that,

What I'm aiming for is:

countAtom to return a promise when its waiting on external data
countAtom to return a value synchronously when the data is available

I'm less convinced than ever than suspense-in-atoms is the way to implement this. Maybe it's actually not too much boilerplate and doing an early return is easier to reason about. I'll attempt a migration to v2 eventually and I should figure something out then.

[pabo]

I am learning jotai, and have no experience with v1. I'm working on a v2 project and have come to the same use case as @Pinpickle : "sync" atoms that depend on async atoms.

Would you still like to write async atoms in the sync style even if you start a new project with v2?

Does this imply there's a different approach that avoids this type of problem?

All atoms sync

One approach I have tried is having all atoms be sync (with sane default values that the components can render sanely, instead of a separate Suspense fallback UI) and then having an init function do my data fetching, and when the data fetching resolves, to synchronously set the atoms needed.

pros: simple, less boiler plate
cons: doesn't use Suspense, need to implement async-ness somewhere which may get messy

// store.ts
const wordsAtom = atom([] as string[]);
const chosenIndexAtom = atom(0);

const chosenWordAtom = atom(get => {
  const chosenIndex = get(chosenIndexAtom);
  const words = get(wordsAtom);
  return words[chosenIndex];
});

const initialize = () => {
  fetch("/wordlist").then((res) => res.json()).then(({ words }) => {
    store.set(wordsAtom, words);
  });
};

initialize();

// component.tsx
const Word = () => {
  const [chosenWord] = useAtom(chosenWordAtom);
  const [chosenIndex, setChosenIndex] = useAtom(chosenIndexAtom);

  const handleSomeEvent = () => {
    // pretend this does something to choose a new chosen word

    setChosenIndex(index);
  };

  return <div>{chosenWord}</div>;
};

async atoms as needed

The other approach is to use async atoms for async data. Additionally any (otherwise sync) atom that references an async atom needs to be converted to async. I think of it as the async atoms infecting all the other atoms. Async creep.

// store.ts
const asyncWordsAtom = atom(
  fetch("/wordlist").then((res) => res.json())
);

const chosenIndexAtom = atom(0);

const chosenWordAtom = atom(async get => {                         // 1
  const chosenIndex = get(chosenIndexAtom);
  const words = await get(asyncWordsAtom);
  return words[chosenIndex];
});

// component.tsx
const Word = () => {
  const [chosenWord] = useAtom(chosenWordAtom, {delay: 0});        // 2
  const [chosenIndex, setChosenIndex] = useAtom(chosenIndexAtom);

  const handleSomeEvent = () => {
    // pretend this does something to choose a new chosen word

    startTransition(() => setChosenIndex(index));                  // 3
  }

  return (
    <Suspense fallback="...loading">
      <div>{chosenWord}</div>;
    </Suspense>
  );
};

If I use any async atom:

1. every other atom that references it must also be async
2. every useAtom needs a {delay: 0} to prevent UI flashing during updates
3. every action that updates an atom needs to be wrapped in startTransition

pros: can use Suspense
cons: more boiler plate, have to keep track of whether an atom is sync or async, unsure of startTransition trade offs

Is this pretty much accurate? I'm just trying to make sure I am not missing any jotai concepts, and that I understand my options here.

[dai-shi]

Check out unwrap for another option.

jotai/docs/utilities/async.mdx

Lines 84 to 92 in f7d7f74

	## unwrap
	The `unwrap` util will convert an async atom to a sync atom like `loadable`.
	Unlike `loadable`, the fallback value can be configured.
	Unlike `loadable`, the error won't be handled and just thrown.
	The use case of `unwrap` is to ease deriving atoms.
	This is especially useful for v2 API,
	because `get` in the read function doesn't resolve promises.

[iwoplaza]

@Pinpickle

What I'm aiming for is:
countAtom to return a promise when its waiting on external data
countAtom to return a value synchronously when the data is available

I recently wrote an implementation of a utility that creates an atom that:

• Suspends when first resolving the asynchronous value
• Stores the last computed value and updates itself in the background

Seems to be exactly what you were describing. It took a couple tries to implement, but it proved very useful in our project's codebase. I have a couple utils like that with interesting properties, might post them as topics here, maybe they will help others looking for these solutions.

[stevemolitor]

I'd like to see that.

I asked a somewhat similar question; see here for solution based on a suggestion from @dai-shi. I wanted to asynchronously fetch an atom value on initial load, but then make synchronous updates to the atom as the user makes edits. So the atom can be either a promise (the initial value) or a regular value (edited value).

The solution was an atom that checks if the value is a promise in its read function. If it's a promise it resolve it first before returning it. This approach could probably be extracted into a reusable util as well. I may try that later if I start to see a pattern in our codebase.

[Pinpickle]

I'd be interested to see the utility, @iwoplaza!

[simon3495]

@iwoplaza Do you mind sharing it?