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.