bvaughn / react-error-boundary

Simple reusable React error boundary component

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Proposal: Catching server errors

tom-sherman opened this issue · comments

So this is just an idea, I'm not 100% sure it actually belongs in a library at all. Looking to hear what your thoughts are!

React doesn't historically have a way to catch errors on the server, but this changed in React 18 with streaming SSR: reactjs/rfcs#215

The React team have expressed other ways of catching errors on the server, but for now the only way of doing it is wrapping your components in a suspense boundary. A common pattern looks something like this:

<ErrorBoundary>
  <Suspense>
    <Component />
  </Suspense>
</ErrorBoundary>

What do you think about including that error boundary in react-error-boundary through some opt in API? Or even by default?

The above code would just become:

<ErrorBoundary>
  <Component />
</ErrorBoundary>

Something I think this can provide is a way to use the error boundary to catch only exceptions, and not pending components. What I mean by this is being able to do this:

<Suspense> // Happens in some parent
  <ErrorBoundary>
    <Component />
  </ErrorBoundary>
</Suspense>

ErrorBoundary could maybe rethrow caught promises and only catch exceptions so that you don't introduce another pending state into your app. Basically the server rendered HTML would show a local error ui, instead of a suspense fallback ui.

What do you think about including that error boundary in react-error-boundary through some opt in API? Or even by default?

The above code would just become:

I think this could cause significant changes in rendering behavior. (Adding a <Suspense> boundary into the UI at an arbitrary or unexpected location could change how an application renders/commits in a significant way.)

I'm not very familiar with server rendering in general so I don't feel super confident making or suggesting changes in that context.

I've restructured this project and released version 4 with a few breaking changes. Now's probably a good time to discuss this if you have thoughts and ideas to share.

Tagging @eps1lon who might also have thoughts here.

My original ask came from a place of having a nicer API for catching suspenseful errors, I don't think this actually is a problem that needs to be solved at the error-boundary level. Better to build this in at the routing layer (loading/error.js in next.js)

I still think using Suspense for catching server errors is a little confusing for newcomers but that's more of a React issue than one that should be solved here.

Sounds reasonable. Going to close this discussion issue out for now then.