Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Catching server errors #129

Closed
tom-sherman opened this issue Feb 21, 2023 · 4 comments
Closed

Proposal: Catching server errors #129

tom-sherman opened this issue Feb 21, 2023 · 4 comments

Comments

@tom-sherman
Copy link

tom-sherman commented Feb 21, 2023

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.

@bvaughn
Copy link
Owner

bvaughn commented Mar 21, 2023

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.

@bvaughn
Copy link
Owner

bvaughn commented Mar 25, 2023

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.

@tom-sherman
Copy link
Author

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.

@bvaughn
Copy link
Owner

bvaughn commented May 19, 2023

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

@bvaughn bvaughn closed this as completed May 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants