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

RFC: Server Rendering Errors in React 18 #215

Merged
merged 2 commits into from
Mar 28, 2022
Merged

RFC: Server Rendering Errors in React 18 #215

merged 2 commits into from
Mar 28, 2022

Conversation

gaearon
Copy link
Member

@gaearon gaearon commented Mar 25, 2022

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.

@gaearon gaearon merged commit b31b370 into main Mar 28, 2022
@somewhatabstract
Copy link

somewhatabstract commented Mar 29, 2022

Is there any way to make the formatted RFC visible to everyone (404s for me at least)?

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

@gaearon
Copy link
Member Author

gaearon commented Mar 29, 2022

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).
Copy link

@tenorok tenorok May 20, 2022

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?

Copy link
Member Author

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?

@dante01yoon
Copy link

This might be outdated question, but I wonder we don't need using lodable components anymore for using Suspense in SSR?

@tranvansang
Copy link

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 <head>.
Otherwise, we need to either load all CSS files or lazily load them all.

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.

@dante01yoon
Copy link

@tranvansang
Isn't it css code splitting could be acquired without using lodable components?
Do you mean importing css file directly in components, not making classes like normal css-in-js, tailwindcss?

@tranvansang
Copy link

Isn't it css code splitting could be acquired without using lodable components?

yes, css code splitting could be acquired without using lodable components

Do you mean importing css file directly in components, not making classes like normal css-in-js, tailwindcss?

That is the case I mentioned. If you use tailwindcss, it is irrelevant.
For css-in-js, I do not have much experiment with SSR + css-in-js.
Previously, when using loadable components, with CSS import, CSS files are included in chunks and I identified which CSS files need for a request.

@dante01yoon
Copy link

I guess not only css files, but also all static files might be loaded

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants