atoms and error boundaries

I’m trying out jotai in one of my projects and it was crashing with code like this

 React.useEffect(() => {
    setState(s => {
      const x = {};
      delete x[123][123];
    });
  });

and I was confused why this error wasn’t caught by the react error boundary (of react-error-boundary fame). Then I realized that my component three was like this JotaiProvider -> ErrorBoundary -> MyComponent so doing something like ErrorBoundary -> JotaiProvider -> ErrorBoundary -> MyComponent helped, but it makes me realize interesting consideration that with smaller context providers I can have them closer to my component and thus making errors more local, but errors in jotai are basically globally scoped 😃

I don’t know if that’s an issue per se, but maybe a good point to consider when deciding between custom context vs global context

[JLarky]

can confirm that v0.10.0 fixes both example on codesandbox and the issue in my app

[dai-shi]

So, with both set*, it shows High level oopsie..., and if we comment out the first one, it shows Oopsie on Crash level.... Good point.

This is because of the place we invoke atom.write function. But, I agree it’s weird. I guess this reveals another issue about batched writes.

We throw errors in render (atom.read) to error boundaries, but for atom.write we throw errors to the write function (even if it’s async write).

I also find my explanation wasn’t so accurate, because it shows error boundaries. I may have misunderstood something.

Let me think if I can write a test case for this.