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);

[edongashi]

I see a recipe in docs for async -> sync atom dependency. How would one handle a chain of two query atoms, where the second one depends on the first one, i.e. async -> async composition?

Concrete example: I need to get an access token via an async call. Then, I need to use that access token to fetch a resource. I want suspense to wait for both operations before showing the resource without state tearing or flickering between them.

In pseudocode this is what I want:

const resourceAtom = atom('resource', ({ get }) => {
    const accessToken = await get(accessTokenAtom);
    const resource = await fetch('/resource', accessToken);
    return resource;
});

A naive injectPromise starts the process with an undefined token. Forwarding the promise is also not logical because I want suspense to wait for both token and resource.

I wrote a helper like this:

export const injectPromiseChain = (nodeDeps, promiseFactory, deps, config) => {
  const nodes = nodeDeps.map((node) =>
    is(node, AtomTemplateBase) ? injectAtomInstance(node) : node
  );
  const rawValues = nodes.map((node) => node.get());
  return injectPromise(
    async (params) => {
      await Promise.all(nodes.map((node) => node.promise).filter((p) => p));
      if (params.controller?.signal.aborted) {
        return undefined;
      }
      return promiseFactory(rawValues.map((value) => ("data" in value ? value.data : value)), params);
    },
    rawValues.concat(deps ?? []),
    config
  );
};

const resourceAtom = atom('resource', () => {
    return injectPromiseChain([accessTokenAtom], ([accessToken], params) => {
        return await fetch('/resource', accessToken)
    });
});

Haven't tested it yet, but does anyone know if there's a more official way to do this?

[bowheart]

Your helper looks great. Tagging #143 again here for another util candidate.

Zedux is pretty low-level here. There are two possible ways I would approach this natively:

• approach 1: Let the state dependency cascade to the promise

const resourceAtom = ion('resource (approach 1)', ({ get }) => {
  const accessToken = get(accessTokenAtom)

  const { dataSignal, promise } = injectPromise(
    async () => {
      if (accessToken) {
        return await doFetch('/resource', accessToken)
      }
    },
    [accessToken]
  )

  return api(dataSignal).setPromise(promise)
})

• approach 2: Chain promises directly

const resourceAtom = ion('resource', ({ getNode }) => {
  const accessTokenNode = getNode(accessTokenAtom)

  // this could be converted to a query atom rather than using `injectPromise`, though that would wrap the data in PromiseState
  const { dataSignal, promise } = injectPromise(
    () => accessTokenNode.promise.then(token => doFetch('/resource', token)),
    [accessTokenNode.promise]
  )

  return api(dataSignal).setPromise(promise)
})

I may have more to add to this soon, but these are the most official patterns for now.

By the way, we might be able to support your pseudo-code if the TC39 async context proposal ever drops.

[edongashi]

Thanks @bowheart! Approach 1 results in "async tearing" if I'm not mistaken, which is what I want to avoid.

Approach 2 looks clean, but I wonder, are we guaranteed that the promise will resolve to the final atom's value? Sometimes you "foward the promise" to trigger suspense, but that promise might resolve to some other value?

const derivedAtom = ion('derived', ({ get, getInstance }) => {
  const asyncInstance = getInstance(asyncAtom)
  const { data } = get(asyncInstance)

  // forward the promise:
  return api(data?.toUpperCase()).setPromise(asyncInstance.promise)
})

function MyComponent() {
  // this component will suspend until this string is defined
  const uppercaseString = useAtomValue(derivedAtom)
}

In this example, does derivedAtom's promise resolve to a lowercase string or an uppercase string?

If the promise is always mapped to the final value then my helper could be simplified significantly.

By the way, we might be able to support your pseudo-code if the TC39 async context proposal ever drops.

Oh yeah, I've been waiting for that proposal for a while now. You can tell so many libraries and frameworks have to work around this problem...