Async Atom: React.StrictMode will abort signal #2610
Unanswered
js-4
asked this question in
Bug report
Replies: 1 comment 2 replies
-
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.
|
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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, theAbortSignal
, 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
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)
Then we wrap the atom in an
loadable()
to avoid using react suspenseAfter 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 lifecycleYou can also toggle the strict mode in the
AppWrapper()
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 unmountedVersions: ["jotai": "2.2.1", "react": "18.0.0",]
Thank you for taking the time to look into this!
Beta Was this translation helpful? Give feedback.
All reactions