React 16.10 broke Next.js/SSR applications

[Timer]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?

React 16.10.0 has broken all Next.js applications (and potentially other SSR solutions).

It appears you cannot hydrate in conjunction with a client-side <Suspense> component.

Expected to have a hydrated suspense instance. This error is likely caused by a bug in React. Please file an issue.

CodeSandbox: https://codesandbox.io/s/i66g1

What is the expected behavior?

Not entirely sure -- I'm opening this issue to discuss. The provided example worked in React 16.9.0 (and prior releases containing Suspense).

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

react@16.10.0/react-dom@16.10.0 is broken.
react@16.9.0/react-dom@16.9.0 works.

[acdlite]

Thanks for reporting! We'll have a fix out soon; in the meantime, please downgrade back to 16.9.0.

[acdlite]

I believe technically we don't support conditionally rendering a Suspense boundary when server rendering. It just happened to (accidentally) work before.

We'll either fix so it matches the old behavior or provide a more graceful error or fallback behavior.

[sebmarkbage]

The issue is that the error only occurred on the server. So if you conditionally rendered it, you’d miss (intentionally?) the error we logged to let you know not to use Suspense with SSR. The issue is that the accidental semantics this lead to, on the client, is not actually the semantics we want SSR Suspense to have. That’s why it was not yet available for SSR.

We’ll at least need this fallback behavior to behave reasonably when the server renders the boundary. https://github.com/facebook/react/blob/master/packages/react-reconciler/src/ReactFiberBeginWork.js#L1970

Now the question is if we can preserve the old accidental behavior if the server was conditionally excluding the boundary on the server. And if that’s even a good idea.

[iksent]

I've just found that error Minified React error #317 today only in my production build of Nextjs. There was no such error yesterday.
But I am having React ^16.8.6 and didn't update any packages.
Is it possible?

[threepointone]

@iksent please file a separate issue. I’d recommend including a reproducing example on codesandbox or as a git repo.

[phamducquanptit]

I got the same error on version react^16.8.4 | react-dom^16.8.4 for my production build of Nextjs. I tried upgrade version react^16.9.0 | react-dom^16.9.0 but it still not resolved

[sebmarkbage]

The key issue here is that with the new model (behind the enableSuspenseServerRenderer flag), this would be considered a hydration error. Something caused a mismatch. We don't know if this is because the boundary was intentionally conditionally rendered, or if it was because something completely different was conditionally hydrated. E.g. consider this <>{c ? <div /> : null}<Suspense>...</Suspense></>. If it rendered the div on the server but not on the client, then the Suspense boundary would have a mismatch because it finds the div where it expected its own content.

I believe we will at least have to make this a hydration error log in DEV mode. So we'll need to find a fix in Next.js regardless. However, as a courtesy we can probably delay that log so there's time to coordinate a fix.

Now the other question is what the runtime semantics should be. In this case, we're already in an error state for hydration so it's not considered normal semantics. I see two possible semantics: 1) it attempts to hydrate using the content of the Suspense boundary. 2) it client-renderers the Suspense boundary content without hydrating and then continues which will likely delete the existing siblings that already had such content.

For (1) it gets quite strange if something suspends because in that case, it would try to hydrate using the fallback's content against the real content which could cause very strange effects.

Normally we favor deleting and regenerating content in these cases because it avoids risks like transferring state or clicks to the wrong target which can cause severe negative effects.

Therefore my preferred semantics here is actually that it regenerates on the client. This is not what Next.js currently assumes will happen though.

[acdlite]

We have a fix for this. I'll release momentarily as 16.10.1. Release branch is here: #16944

[acdlite]

This is now fixed in v16.10.1.

[threepointone]

@damiangreen please file a new issue with a reproducing example, either on codesandbox, or as a git repo. Thank you!