Preferred way to wait for another atom to resolve?

[devnomic]

Is this the preferred way to write it in zedux because i didn't see (or miss) the pattern in docs.

// I have a suspending atom
const nameAtom = atom("name", () => {
  const store = injectStore("No name", { subscribe: false });
  const promise = (async () => {
    await new Promise((resolve) => setTimeout(resolve, 3000));
    return store.setState("John Doe");
  })();

  return api(store).setPromise(promise);
});

const otherAtom = atom("other", () => {
  const nameInstance = injectAtomInstance(nameAtom);

  // This doesn't work well because name is promise atom?
  // const name = injectAtomValue(nameAtom);

  return api().setExports({
   // I want to call say name but need to make sure name atom already resolved.
    sayName: async () => {
      // Is this the preferred method to make sure name atom already resolved?
      // Await using it's promise
      await nameInstance.promise;
      console.log(nameInstance.getState());
    }
  });
});

https://codesandbox.io/s/zedux-async-function-orx3sd?file=/src/App.tsx

[bowheart]

I should document managing multiple asynchronous atoms better.

Yes. In Zedux, asynchrony is managed outside atom evaluation. This gives you full control over asynchrony at the cost of having to exercise that control. Awaiting nameInstance.promise there is an example of this. It's an extra line of code you wouldn't have to write with Recoil/Jotai. But the tradeoff is you can do whatever you want - e.g. using RxJS to dynamically merge/buffer/throttle/etc multiple async flows.

An early prototype of Zedux actually made atoms asynchronous like Recoil/Jotai. We got rid of it 'cause we needed this extra control.

Btw you can forward promises if you want to use suspense with otherAtom:

return api().setPromise(nameInstance.promise)

Also with exports, one thing to watch out for is something force-destroying the nameAtom instance. That would make otherAtom reevaluate and injectAtomInstance(nameAtom) return a new instance reference. Which means the sayName export has closed over a stale value.

const otherAtom = atom("other", () => {
  const { getInstance } = injectAtomGetters();
  getInstance(nameAtom); // register a graph dependency, but don't use it here

  return api().setExports({
    sayName: async () => {
      const nameInstance = getInstance(nameAtom); // get the instance here
      await nameInstance.promise;
      console.log(nameInstance.getState());
    }
  });
});

If the atom takes params, it may be more convenient to pass the possibly-destroyed instance directly to getInstance() inside sayName.

Here's an example combining all these tips.

In practice, this is up to you. I always guard against force-destruction in case someone else comes along and force-destroys an atom. But you could of course make it a convention in your app to just never force-destroy. You can get along without that feature.

[devnomic]

Thank you for sharing these best practices guide, which is indeed what i need to prevent common mistake later on.

Yes, i also like zedux full control of async flow.

[devnomic]

@bowheart I also wanted to ask question about writing the atom in sync manner but forward the promise, is it considered ok? or better to write it inside promise?

const nameAtom = atom("name", () => {
  const store = injectStore("No name", { subscribe: false });
  const promise = (async () => {
    await new Promise((resolve) => setTimeout(resolve, 1000));
    return store.setState("John Doe");
  })();

  return api(store).setPromise(promise);
});

const titleAtom = atom("title", () => {
  const store = injectStore("No Title", { subscribe: false });
  const promise = (async () => {
    await new Promise((resolve) => setTimeout(resolve, 2000));
    return store.setState("Mr");
  })();

  return api(store).setPromise(promise);
});

// Is writing the atom implementation in sync manner
// but add setPromise could leads to bugs later on?
// or this kind of code is ok?
const fullNameAtom = ion("fullName", ({ get, getInstance }) => {
  const nameInstance = getInstance(nameAtom);
  const titleInstance = getInstance(titleAtom);

  const name = get(nameAtom);
  const title = get(titleAtom);

  const fullName = `${title}. ${name}`;
  return api(fullName).setPromise(
    Promise.all([nameInstance.promise, titleInstance.promise])
  );
});

// Or is it generally better to code the atom like this for more safer approach?
const fullName2Atom = ion("fullName2", ({ get, getInstance }) => {
  // Register graph but don't use it here
  getInstance(nameAtom);
  getInstance(titleAtom);

  const promise = (async () => {
    // Do we need to guard force destruction also for promise? (i think so?)
    const nameInstance = getInstance(nameAtom);
    const titleInstance = getInstance(titleAtom);

    await Promise.all([nameInstance.promise, titleInstance.promise]);

    const name = nameInstance.getState();
    const title = titleInstance.getState();

    return `${title}. ${name}`;
  })();

  return api(promise);
});

https://codesandbox.io/s/zedux-nested-async-atoms-forked-uxhewr?file=/src/App.tsx:182-1909

[devnomic]

After doing console.log It seems writing in sync manner the atom will be evaluated multiple times, so i think it's better to use the second approach.

[bowheart]

Force destruction is only a concern with exports - since exports never change, they hold onto any closed over values forever.

Promises do change. Either approach is fine if you memoize the Promise.all() promise reference

const promises = [nameInstance.promise, titleInstance.promise];
const promise = injectMemo(() => Promise.all(promises), promises);

const fullName = `${title}. ${name}`;
return api(fullName).setPromise(promise);