-
Notifications
You must be signed in to change notification settings - Fork 559
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
RFC: Server Rendering Errors in React 18 #215
Conversation
…rors-in-react-18.md
The link is broken in the PR. This link works for me, though it may not be the final link: https://github.com/reactjs/rfcs/blob/ba9bd5744cb922184ec9390515910cd104a30c6e/text/0215-server-errors-in-react-18.md |
Oops, sorry. Updated! |
|
||
# Motivation | ||
|
||
There used to be no way to handle a rendering error on the server, so any component error was fatal and deopted the entire app to a full client render (or, depending on how your app is set up, would completely break it). On the client, errors are handled by error boundaries. But error boundaries don't work on the server because they rely on state. Although it's possible there will later be a separate error boundary API for the server, in the meantime, this change provides a natural way for the app to recover from error. Since server and client run the same code, it is possible that the client will be able to succeed (e.g. if the error was caused by some server-only problem). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the client, errors are handled by error boundaries.
But componentDidCatch
not catching synchronously errors, which can be thrown on first render when hydration run.
For example:
function MyComponent() {
// Explicit example, it can be any error.
throw new Error('Undefined is not a function);
return <div>Hello world!</div>;
}
If we wraps MyComponent
in ErrorBoundary
the error above will crash application entirely during call ReactDOM.hydrate()
.
Do you have any solution for this case or may be I do something wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please file an issue with a reproducing case?
This might be outdated question, but I wonder we don't need using lodable components anymore for using Suspense in SSR? |
There is a minor case that is only achievable by using loadable components (disclose: I am the maintainer of @react-loadable/revised) With loadable components: we know which CSS files are required and insert them to Because the effect is small, I drop react-loadable completely in my projects and replace with react native methods (lazy, suspense) and load all CSS files in every request regardless of whether they are required or not. Hope that this helps. |
@tranvansang |
yes, css code splitting could be acquired without using lodable components
That is the case I mentioned. If you use tailwindcss, it is irrelevant. |
I guess not only css files, but also all static files might be loaded |
In this RFC, we describe a mechanism in React 18 that allows apps to recover from server rendering errors automatically by wrapping parts of the tree into
<Suspense>
boundaries. Additionally, React does not attempt to "patch up" individual nodes on hydration mismatches and instead relies on the same mechanism to retry rendering a part of the tree on the client.View the formatted RFC.