Unable to await an async writable atom from another async writable atom

[acusti]

i am using jotai for my auth flow and have a number of async writable (write-only) atoms. some of them depend on other async writable atoms. i tried to use await set(otherAsyncAtom); to trigger the other async atom and wait for it to complete, but execution continues immediately (no awaiting).

here’s a simple (contrived) demonstration of the issue, using console.log to show when each part of the async writable atoms execute: https://codesandbox.io/s/jotai-await-async-set-2esbb

is this the expected behavior? and if so, is there a different way to accomplish what i am looking for? thanks for all of your assistance and for an excellent library!

[dai-shi]

This is the expected behavior but we are not happy with it.
Related issues: #607, old #204.

I made it return a promise once before v1. It didn't feel like a right abstraction, as it returns promise conditionally.
Implementation-wise, it was too tricky. The issue is, from the library perspective, we don't know if otherAsyncAtom is async or not in advance.

As I understand your expectation, I would like to revisit this along with #607.
(Now, I think there's a more straightforward way. void | Promise<void> seems fine.)

---

Meanwhile, the workaround I can think of is the use of traditional callback.

const fooAtom = atom(null, async (get, set, callback) => {
  await resolveAfter2Seconds();
  console.log("END fooAtom write (should be 3rd)");
  callback();
});

const barAtom = atom(null, (get, set) => {
  set(fooAtom, () => {
    console.log("END barAtom write (should be 4th)");
  });
});

But, this is ugly...

[acusti]

i agree that having set(writeAtom) return void | Promise<void> depending on whether or not it returns a promise (e.g. is async) makes sense. i expected the same from useAtom also:

  const [, triggerAction] = useAtom(triggerActionAtom);
  const [isActionComplete, setIsActionComplete] = useState(false);

  const handleClick = useCallback(() => {
    const executeAction = async () => {
      await triggerAction();
      setIsActionComplete(true);
    };

    executeAction();
  }, [triggerAction]);

but now i’m thinking that await triggerAction(); has the same problem as await set(triggerActionAtom);

---

considering that making an async write-only atom means you are actually returning a value (Promise<void>), i decided to try implementing these as read-only atoms, where the read function is a thunk:

function resolveAfter2Seconds() {
  console.log("START resolveAfter2Seconds (should be 1st)");
  return new Promise((resolve) => {
    setTimeout(function () {
      resolve("slow");
      console.log("END resolveAfter2Seconds (should be 2nd)");
    }, 2000);
  });
}

const fooAtom = atom((get) => async () => {
  await resolveAfter2Seconds();
  console.log("END fooAtom read (should be 3rd)");
});

const barAtom = atom((get) => async () => {
  await get(fooAtom)();
  console.log("END barAtom read (should be 4th)");
});

it seems to work, and using a thunk means that the returned function can take arguments. however, not being able to invoke set(...) from the resulting actions is a pretty major limitation. in codesandbox: https://codesandbox.io/s/jotai-await-async-get-forked-m1ncn

[dai-shi]

Yea, it's the same problem (and the same fix). Note read works for async, but no side effects are allowed in read.

I will work on it, and will ask you to test it.