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

Unhide Suspense trees without entanglement #18733

Closed

Conversation

acdlite
Copy link
Collaborator

@acdlite acdlite commented Apr 25, 2020

When a Suspense boundary is in its fallback state, you cannot switch back to the main content without also finishing any updates inside the tree that might have been skipped. That would be a form of tearing.

Before we fixed this in #18411, the way this bug manifested was that a boundary was suspended by an update that originated from a child component (as opposed to props from a parent). While the fallback was showing, it received another update, this time at high priority. React would render the high priority update without also including the original update. That would cause the fallback to switch back to the main content, since the update that caused the tree to suspend was no longer part of the render. But then, React would immediately try to render the original update, which would again suspend and show the fallback, leading to a momentary flicker in the UI.

The approach added in #18411 is, when receiving a high priority update to a Suspense tree that's in its fallback state is to bail out, keep showing the fallback and finish the update in the rest of the tree. After that commits, render again at the original priority. Because low priority expiration times are inclusive of higher priority expiration times, this ensures that all the updates are committed together.

The new approach in this commit is to turn renderExpirationTime into a context-like value that lives on the stack. Then, when unhiding the Suspense boundary, we can push a new renderExpirationTime that is inclusive of both the high pri update and the original update that suspended. Then the boundary can be unblocked in a single render pass.

An advantage of the old approach is that by deferring the work of unhiding, there's less work to do in the high priority update.

The key advantage of the new approach is that it solves the consistency problem without having to entangle the entire root.

@facebook-github-bot facebook-github-bot added React Core Team Opened by a member of the React Core Team CLA Signed labels Apr 25, 2020
@sizebot
Copy link

sizebot commented Apr 25, 2020

Details of bundled changes.

Comparing: ac533fd...9ea9c5f

react-dom

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-dom-test-utils.development.js 0.0% 0.0% 75.23 KB 75.23 KB 20.16 KB 20.16 KB UMD_DEV
react-dom-unstable-fizz.browser.development.js 0.0% +0.1% 5.26 KB 5.26 KB 1.77 KB 1.77 KB UMD_DEV
react-dom.development.js 0.0% 0.0% 942.22 KB 942.22 KB 206.23 KB 206.23 KB UMD_DEV
ReactDOMForked-dev.js +0.1% 0.0% 1009.55 KB 1010.06 KB 224.79 KB 224.88 KB FB_WWW_DEV
react-dom-server.browser.production.min.js 0.0% 0.0% 23.43 KB 23.43 KB 8.61 KB 8.61 KB UMD_PROD
ReactDOMForked-prod.js 🔺+0.1% 🔺+0.1% 422.95 KB 423.24 KB 74.08 KB 74.15 KB FB_WWW_PROD
ReactDOMForked-profiling.js +0.1% +0.1% 433.29 KB 433.58 KB 75.81 KB 75.88 KB FB_WWW_PROFILING
react-dom-server.browser.development.js 0.0% -0.0% 152.64 KB 152.64 KB 40.49 KB 40.48 KB NODE_DEV
react-dom-server.browser.production.min.js 0.0% 0.0% 23.32 KB 23.32 KB 8.6 KB 8.6 KB NODE_PROD
ReactDOM-dev.js 0.0% 0.0% 1014.27 KB 1014.27 KB 226.14 KB 226.14 KB FB_WWW_DEV
ReactDOMServer-prod.js 0.0% 0.0% 52.01 KB 52.01 KB 12.55 KB 12.55 KB FB_WWW_PROD
react-dom-test-utils.production.min.js 0.0% 0.0% 13.12 KB 13.12 KB 4.81 KB 4.81 KB NODE_PROD
react-dom-unstable-fizz.browser.production.min.js 0.0% 🔺+0.2% 1.02 KB 1.02 KB 616 B 617 B NODE_PROD
react-dom-server.node.development.js 0.0% -0.0% 153.86 KB 153.86 KB 40.74 KB 40.74 KB NODE_DEV

react-cache

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-cache.production.min.js 0.0% 🔺+0.1% 2.36 KB 2.36 KB 1.2 KB 1.2 KB UMD_PROD
ReactCache-dev.js +706.6% +391.1% 1.01 KB 8.16 KB 553 B 2.65 KB FB_WWW_DEV
ReactCache-prod.js 🔺+369.4% 🔺+165.0% 1.08 KB 5.09 KB 608 B 1.57 KB FB_WWW_PROD

Size changes (experimental)

Generated by 🚫 dangerJS against 9ea9c5f

@sizebot
Copy link

sizebot commented Apr 25, 2020

Details of bundled changes.

Comparing: ac533fd...9ea9c5f

react-dom

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
ReactDOM-profiling.js 0.0% 0.0% 444.03 KB 444.03 KB 77.77 KB 77.77 KB FB_WWW_PROFILING
react-dom-test-utils.production.min.js 0.0% 0.0% 13.1 KB 13.1 KB 4.8 KB 4.8 KB NODE_PROD
react-dom-server.browser.development.js 0.0% -0.0% 154.84 KB 154.84 KB 39.46 KB 39.46 KB UMD_DEV
react-dom-server.browser.production.min.js 0.0% -0.0% 22.97 KB 22.97 KB 8.53 KB 8.53 KB UMD_PROD
ReactDOMForked-dev.js 0.0% 0.0% 1.01 MB 1.01 MB 230.33 KB 230.42 KB FB_WWW_DEV
ReactDOMForked-prod.js 🔺+0.1% 🔺+0.1% 434.41 KB 434.78 KB 76.07 KB 76.17 KB FB_WWW_PROD
react-dom.development.js 0.0% 0.0% 908.34 KB 908.34 KB 199.77 KB 199.77 KB UMD_DEV
ReactDOMForked-profiling.js +0.1% +0.1% 444.81 KB 445.19 KB 77.82 KB 77.89 KB FB_WWW_PROFILING
react-dom.production.min.js 0.0% -0.0% 119.97 KB 119.97 KB 38.45 KB 38.45 KB UMD_PROD
react-dom.profiling.min.js 0.0% 0.0% 123.74 KB 123.74 KB 39.66 KB 39.66 KB UMD_PROFILING
ReactDOMTesting-dev.js 0.0% 0.0% 935.96 KB 935.96 KB 208.76 KB 208.76 KB FB_WWW_DEV
react-dom.development.js 0.0% -0.0% 864.63 KB 864.63 KB 197.24 KB 197.24 KB NODE_DEV
ReactDOMTesting-prod.js 0.0% 0.0% 390.82 KB 390.82 KB 71.16 KB 71.17 KB FB_WWW_PROD
react-dom-server.node.development.js 0.0% -0.0% 146.91 KB 146.91 KB 38.94 KB 38.94 KB NODE_DEV
react-dom.production.min.js 0.0% -0.0% 120.09 KB 120.09 KB 37.66 KB 37.66 KB NODE_PROD
react-dom-test-utils.development.js 0.0% 0.0% 75.22 KB 75.22 KB 20.15 KB 20.15 KB UMD_DEV
ReactDOMTesting-profiling.js 0.0% 0.0% 390.82 KB 390.82 KB 71.16 KB 71.17 KB FB_WWW_PROFILING
react-dom-server.node.production.min.js 0.0% -0.0% 23.27 KB 23.27 KB 8.67 KB 8.67 KB NODE_PROD
react-dom.profiling.min.js 0.0% -0.0% 123.98 KB 123.98 KB 38.82 KB 38.82 KB NODE_PROFILING
ReactDOM-dev.js 0.0% 0.0% 1.02 MB 1.02 MB 231.67 KB 231.67 KB FB_WWW_DEV
react-dom-test-utils.development.js 0.0% 0.0% 70.06 KB 70.06 KB 19.64 KB 19.65 KB NODE_DEV
react-dom-unstable-fizz.node.development.js 0.0% +0.1% 5.5 KB 5.5 KB 1.82 KB 1.82 KB NODE_DEV
react-dom-server.browser.development.js 0.0% -0.0% 145.69 KB 145.69 KB 38.69 KB 38.69 KB NODE_DEV
react-dom-server.browser.production.min.js 0.0% -0.0% 22.87 KB 22.87 KB 8.51 KB 8.51 KB NODE_PROD
react-dom-unstable-fizz.browser.production.min.js 0.0% 🔺+0.1% 1.19 KB 1.19 KB 696 B 697 B UMD_PROD
ReactDOMServer-prod.js 0.0% 0.0% 52.9 KB 52.9 KB 12.74 KB 12.74 KB FB_WWW_PROD
react-dom-unstable-fizz.browser.production.min.js 0.0% 🔺+0.2% 1 KB 1 KB 608 B 609 B NODE_PROD

react

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react-unstable-cache.production.min.js 0.0% 🔺+0.2% 855 B 855 B 554 B 555 B NODE_PROD
react.production.min.js 0.0% 0.0% 11.39 KB 11.39 KB 4.55 KB 4.55 KB UMD_PROD
react-jsx-runtime.profiling.min.js 0.0% +0.2% 946 B 946 B 593 B 594 B NODE_PROFILING
react-unstable-cache.development.js 0.0% +0.2% 1.04 KB 1.04 KB 579 B 580 B NODE_DEV
react.profiling.min.js 0.0% 0.0% 14.9 KB 14.9 KB 5.63 KB 5.63 KB UMD_PROFILING
ReactCache-dev.js -87.6% -79.6% 8.16 KB 1.01 KB 2.65 KB 553 B FB_WWW_DEV
react.development.js 0.0% 0.0% 63.5 KB 63.5 KB 17.13 KB 17.13 KB NODE_DEV
ReactCache-prod.js -78.7% -62.3% 5.09 KB 1.08 KB 1.57 KB 608 B FB_WWW_PROD
react.production.min.js 0.0% 0.0% 6.32 KB 6.32 KB 2.62 KB 2.62 KB NODE_PROD
React-dev.js 0.0% -0.0% 98.87 KB 98.87 KB 24.18 KB 24.18 KB FB_WWW_DEV
React-prod.js 0.0% 0.0% 17.4 KB 17.4 KB 4.55 KB 4.55 KB FB_WWW_PROD
React-profiling.js 0.0% 0.0% 17.4 KB 17.4 KB 4.55 KB 4.55 KB FB_WWW_PROFILING

ReactDOM: size: 0.0%, gzip: -0.0%

React: size: 0.0%, gzip: 0.0%

Size changes (stable)

Generated by 🚫 dangerJS against 9ea9c5f

@acdlite acdlite force-pushed the unhide-suspense-trees-without branch from 64ac432 to f8c42fb Compare April 25, 2020 07:14
@codesandbox-ci
Copy link

codesandbox-ci bot commented Apr 25, 2020

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 9ea9c5f:

Sandbox Source
modest-einstein-5oglj Configuration

@acdlite acdlite force-pushed the unhide-suspense-trees-without branch from f8c42fb to e7e3288 Compare April 25, 2020 07:29
@acdlite acdlite force-pushed the unhide-suspense-trees-without branch from e7e3288 to c40d206 Compare April 25, 2020 07:50
@@ -3384,6 +3379,10 @@ function beginWork(
return null;
}
}
case OffscreenComponent: {
pushRenderExpirationTime(workInProgress, renderExpirationTime);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could optimize this slightly by pushing only when the component is hidden

When a Suspense boundary is in its fallback state, you cannot switch
back to the main content without also finishing any updates inside the
tree that might have been skipped. That would be a form of tearing.

Before we fixed this in facebook#18411, the way this bug manifested was that a
boundary was suspended by an update that originated from a child
component (as opposed to props from a parent). While the fallback was
showing, it received another update, this time at high priority. React
would render the high priority update without also including the
original update. That would cause the fallback to switch back to the
main content, since the update that caused the tree to suspend was no
longer part of the render. But then, React would immediately try to
render the original update, which would again suspend and show the
fallback, leading to a momentary flicker in the UI.

The approach added in facebook#18411 is, when receiving a high priority update
to a Suspense tree that's in its fallback state is to bail out, keep
showing the fallback and finish the update in the rest of the tree.
After that commits, render again at the original priority. Because low
priority expiration times are inclusive of higher priority expiration
times, this ensures that all the updates are committed together.

The new approach in this commit is to turn `renderExpirationTime` into a
context-like value that lives on the stack. Then, when unhiding the
Suspense boundary, we can push a new `renderExpirationTime` that is
inclusive of both the high pri update and the original update that
suspended. Then the boundary can be unblocked in a single render pass.

An advantage of the old approach is that by deferring the work of
unhiding, there's less work to do in the high priority update.

The key advantage of the new approach is that it solves the consistency
problem without having to entangle the entire root.
@acdlite acdlite force-pushed the unhide-suspense-trees-without branch from 3d841d7 to 9ea9c5f Compare May 1, 2020 00:03
@acdlite
Copy link
Collaborator Author

acdlite commented May 1, 2020

Closed by #18782

@acdlite acdlite closed this May 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed React Core Team Opened by a member of the React Core Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants