Async Atom: React.StrictMode will abort signal

[js-4]

Hello everyone,
I've encountered an issue where using jotai/utils/loadable with an "async atom" in a React Strict Mode environment doesn't seem to be working as expected. Since React 18 Strict Mode, each component will render twice to "help to accidentally find impure code". Because of that, the AbortSignal, that is provided by the atom getter option is getting aborted during the unmount. This in turn leads to functions such as fetch triggering an exception (‘AbortError’). After remount, no new/further state snapshot is created, which means that the loadable atom remains in an error state.

Steps to Reproduce:
I created a codesandbox which documents the behavior

• observe the initial load behavior in strict mode (a abort error is present)
• remove the strict mode, to get an working app

Codesandbox.io

Code Breakdown
We frist need to create an Atom with an async getter, which rejects the async work, if the signal is getting aborted (like the fetch api does)

const asyncAtom = atom(async (_get, { signal }) => {
  // log that we started a new snapshot getter
  console.log("started async work...");

  // hoist promise handler
  let resolve: (value: string) => void;
  let reject: (err: any) => void;

  const promise = new Promise<string>((res, rej) => {
    resolve = res;
    reject = rej;
  });

  // simulate async work with 1s delay
  const timeoutId = setTimeout(() => resolve("done"), 1000);

  // listen to the abort signal
  signal.addEventListener("abort", () => {
    // this only happens in strict mode because the component will remounts
    console.log("abort signal was aborted");

    // cancel async work
    clearTimeout(timeoutId);

    // induce a abort error like "fetch"
    reject(new Error("Aborted"));
  });

  return promise;
});

Then we wrap the atom in an loadable() to avoid using react suspense

const asyncLoadableAtom = loadable(asyncAtom);

After all we then just use the atom value using useAtomValue() in the App Component. The state here simply gets visualized. I also added an useEffect to log the component lifecycle

function App() {
  const value = useAtomValue(asyncLoadableAtom);

  useEffect(() => {
    console.log("App mounted (in strict mode twice)");

    return () => console.log("App unmounted");
  }, []);

  return (
    <>
      <h1>Hello Jotai & React 18</h1>
      <ul>
        <li>
          "Always" restart the app after modifications by reloading the tab to
          get initial load behavior
        </li>
        <li>Check the console</li>
        <li>Toggle the strict mode</li>
      </ul>
      {value.state === "loading" && <>Loading...</>}
      {value.state === "hasData" && <>Success: {value.data}</>}
      {value.state === "hasError" && (
        <>Error: {(value.error as Error)?.message}</>
      )}
      <br />
      <br />
      {JSON.stringify(value)}
    </>
  );
}

You can also toggle the strict mode in the AppWrapper()

function AppWrapper() {
  const useStrictMode = true;

  return useStrictMode ? (
    <React.StrictMode>
      <App />
    </React.StrictMode>
  ) : (
    <App />
  );
}

The problematic behaviour is after remounting in strict mode, which causes the asyncAtom to remain in the aborted error state.

Other Nodes:

• this behavior is not present, if you are using the useAtom api + React.Suspense because the suspended component seems to not get unmounted

• Versions: ["jotai": "2.2.1", "react": "18.0.0",]

Thank you for taking the time to look into this!

[dai-shi]

Not 100% following, but it's probably an uncovered use case. Yeah, it is a bug in that case.

I need help from you or someone.
Steps are:

1. Reproduce the bug with test. Preferably, only with store apis. tests/vanilla/store.test.tsx
2. Propose a fix to cover it.

[js-4]

Thank you for your assessment. Unfortunately, I am not familiar with the source code. However, I can still have a look at the tests when I get the chance. With that being said, I would suspect that the problem is probably in the loadable() area in conjunction with useAtomValue(). But shouldn't I then create a test for it under the React part jotai/tests/react?

[dai-shi]

Yeah, if the problem is in loadable, the test should be in tests/react.

Contributing to step 1 is still very helpful. Step 2 could be done by someone else. Thanks.