Reuse SSR fallback instead of remounting when hydration suspends on client data - #37644
ShravanthReddy wants to merge 1 commit into
Conversation
|
Hi @ShravanthReddy! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
When a Suspense boundary is client-rendered on the server, the server emits the fallback as a permanent fallback (
<!--$!-->). If hydration's first client render suspends again (e.g. on a client-created promise), React was deleting the server-rendered fallback DOM and mounting an identical new fallback. Same pixels, different nodes: CSS animations restart and DOM state is lost.This change keeps the dehydrated fallback fragment in place as the fallback branch when the boundary re-suspends during hydration, instead of remounting it. The fix is gated on permanent server fallbacks only, so normal hydration and mismatch behavior are untouched.
Fixes #37620.
Tests: added three tests to
ReactDOMFizzServer-test.js: regression (fallback node identity across hydration), control (fallback still replaced when hydration doesn't suspend), and re-suspension (second promise suspending before the first resolves).