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

Proposed new Suspense layout effect semantics #21079

Merged
merged 4 commits into from
Apr 6, 2021

Conversation

bvaughn
Copy link
Contributor

@bvaughn bvaughn commented Mar 24, 2021

This PR contains a proposed change to layout effect semantics within Suspense subtrees: If a component mounts within a Suspense boundary and is later hidden (because of something else suspending) React will cleanup that component’s layout effects (including React-managed refs).

This change will hopefully fix existing bugs that occur because of things like reading layout in a hidden tree and will also enable a point at which to e.g. pause videos and hide user-managed portals. After the suspended boundary resolves, React will setup the component’s layout effects again (including React-managed refs).

The scenario described above is not common. The useTransition API should ensure that Suspense does not revert to its fallback state after being mounted.

Note that these changes are primarily written in terms of the (as of yet internal) Offscreen API as we intend to provide similar effects semantics within recently shown/hidden Offscreen trees in the future. (More to follow.)

(Note that all changes in this PR are behind a new feature flag, enableSuspenseLayoutEffectSemantics, which is disabled for now.)

Breakdown

This PR is split into a few commits:

  1. First, a new feature flag (enableSuspenseLayoutEffectSemantics) enabled for variant tests only (__VARIANT__) and toggleable by a GK in Facebook builds.
  2. A new test suite (ReactSuspenseEffectsSemantics-test.js) covering the changes to layout effects and refs semantics.
  3. The actual reconciler changes to layout effects and refs semantics. (This is the commit to review.)
  4. Gating a fuzz test (ReactSuspenseFuzz-test.internal.js) that fails b'c of the changed semantics. (The failure is expected. A comment was left explaining why.)

Checklist

  • Audit feature flags to make sure DCE works (including for nested if/else statements). OSS build contains no references to RefStatic/LayoutStatic flags, enableSuspenseLayoutEffectSemantics feature flag, or offscreenSubtree* stack variables.
  • Final audit for naming and inline comments.
  • Fix failing ReactLazy-test.internal.js test.
  • Gated failing ReactSuspenseFuzz-test.internal.js test with an explanatory comment.

@facebook-github-bot facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Mar 24, 2021
@sizebot
Copy link

sizebot commented Mar 24, 2021

Comparing: b48b38a...8c191e8

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name +/- Base Current +/- gzip Base gzip Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js = 122.62 kB 122.63 kB = 39.34 kB 39.34 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js = 129.19 kB 129.19 kB +0.01% 41.42 kB 41.43 kB
facebook-www/ReactDOM-prod.classic.js +1.62% 405.80 kB 412.38 kB +1.11% 75.37 kB 76.21 kB
facebook-www/ReactDOM-prod.modern.js +1.62% 394.06 kB 400.44 kB +1.11% 73.51 kB 74.33 kB
facebook-www/ReactDOMForked-prod.classic.js +1.62% 405.80 kB 412.38 kB +1.11% 75.37 kB 76.21 kB
facebook-www/ReactART-prod.classic.js +2.32% 261.32 kB 267.38 kB +1.81% 46.56 kB 47.41 kB
facebook-www/ReactART-prod.modern.js +2.31% 253.96 kB 259.81 kB +1.81% 45.32 kB 46.14 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show
Name +/- Base Current +/- gzip Base gzip Current gzip
facebook-www/ReactART-prod.classic.js +2.32% 261.32 kB 267.38 kB +1.81% 46.56 kB 47.41 kB
facebook-www/ReactART-prod.modern.js +2.31% 253.96 kB 259.81 kB +1.81% 45.32 kB 46.14 kB
facebook-www/ReactDOM-profiling.classic.js +1.68% 427.63 kB 434.81 kB +1.26% 78.97 kB 79.96 kB
facebook-www/ReactDOMForked-profiling.classic.js +1.68% 427.63 kB 434.81 kB +1.26% 78.97 kB 79.97 kB
facebook-www/ReactDOM-profiling.modern.js +1.68% 415.86 kB 422.83 kB +1.26% 77.15 kB 78.12 kB
facebook-www/ReactDOMForked-profiling.modern.js +1.68% 415.86 kB 422.83 kB +1.26% 77.15 kB 78.12 kB
facebook-www/ReactDOM-prod.classic.js +1.62% 405.80 kB 412.38 kB +1.11% 75.37 kB 76.21 kB
facebook-www/ReactDOMForked-prod.classic.js +1.62% 405.80 kB 412.38 kB +1.11% 75.37 kB 76.21 kB
facebook-www/ReactDOM-prod.modern.js +1.62% 394.06 kB 400.44 kB +1.11% 73.51 kB 74.33 kB
facebook-www/ReactDOMForked-prod.modern.js +1.62% 394.06 kB 400.44 kB +1.11% 73.51 kB 74.33 kB
facebook-www/ReactART-dev.modern.js +1.26% 691.48 kB 700.17 kB +1.06% 147.52 kB 149.10 kB
facebook-www/ReactART-dev.classic.js +1.24% 701.77 kB 710.46 kB +1.05% 149.58 kB 151.15 kB
facebook-www/ReactIs-dev.classic.js +1.03% 9.82 kB 9.92 kB +0.78% 2.68 kB 2.70 kB
facebook-www/ReactIs-dev.modern.js +1.00% 10.09 kB 10.19 kB +0.73% 2.72 kB 2.74 kB
facebook-www/SchedulerTracing-dev.modern.js +0.91% 11.11 kB 11.21 kB +0.98% 2.45 kB 2.48 kB
facebook-www/SchedulerTracing-dev.classic.js +0.91% 11.11 kB 11.21 kB +0.98% 2.45 kB 2.48 kB
facebook-www/ReactDOMForked-dev.modern.js +0.84% 1,029.91 kB 1,038.59 kB +0.69% 228.95 kB 230.52 kB
facebook-www/ReactDOM-dev.modern.js +0.84% 1,029.91 kB 1,038.59 kB +0.69% 228.95 kB 230.52 kB
facebook-www/ReactDOMForked-dev.classic.js +0.82% 1,056.15 kB 1,064.84 kB +0.68% 234.38 kB 235.98 kB
facebook-www/ReactDOM-dev.classic.js +0.82% 1,056.15 kB 1,064.84 kB +0.69% 234.38 kB 235.98 kB
facebook-www/JSXDEVRuntime-dev.modern.js +0.24% 41.87 kB 41.97 kB +0.20% 11.72 kB 11.75 kB
facebook-www/JSXDEVRuntime-dev.classic.js +0.24% 41.87 kB 41.97 kB +0.20% 11.72 kB 11.75 kB

Generated by 🚫 dangerJS against 8c191e8

@Andarist
Copy link
Contributor

This only touches layout effects (so kinda a good thing - considering they are less common in applications, so the impact is minimized). From the comments/tweets in the past I was under the impression that such a change is being discussed for all effects - was it always specifically about layout effects and I've just assumed the other intention? Or maybe passive effects got excluded from that in the process of experimenting with it? Is there any plan to experiment with similar semantics for passive effects?

Are React-managed refs those that are passed to the ref prop? Or is there anything else to it? Would it make sense to add a dev-only warning about non-React write attempts to React-managed refs? From what I see there is no such warning. Doing something like this was always not the best idea and I haven't actually seen any code doing it but maybe worth adding something like this nevertheless.

@bvaughn
Copy link
Contributor Author

bvaughn commented Mar 24, 2021

This only touches layout effects (so kinda a good thing - considering they are less common in applications, so the impact is minimized). From the comments/tweets in the past I was under the impression that such a change is being discussed for all effects - was it always specifically about layout effects and I've just assumed the other intention? Or maybe passive effects got excluded from that in the process of experimenting with it? Is there any plan to experiment with similar semantics for passive effects?

@Andarist: See this comment in the PR:

Note that these changes are primarily written in terms of the (as of yet internal) Offscreen API as we intend to provide similar effects semantics within recently shown/hidden Offscreen trees in the future. (More to follow.)

We plan to offer a way to cleanup passive effects as well. This is just an incremental step.

Are React-managed refs those that are passed to the ref prop?

React-managed refs are when a ref attribute is set on a host component (e.g. <div>), a class component, or a function component that uses the useImperativeHandle API.

@Andarist
Copy link
Contributor

We plan to offer a way to cleanup passive effects as well. This is just an incremental step.

Will this be controllable by the user for passive effects?

React-managed refs are when a ref attribute is set on a host component (e.g.

), a class component, or a function component that uses the useImperativeHandle API.

Gotcha, that's what I thought - thanks for clarifying 👍

@bvaughn
Copy link
Contributor Author

bvaughn commented Mar 24, 2021

@Andarist We'll provide more detail about this soon 😄 ("More to follow.")

@Andarist
Copy link
Contributor

Ok, I'll practice being patient. It ain't easy though! 😅

Comment on lines 481 to 483
current !== null &&
(current.flags & PassiveStaticEffect) !==
(workInProgress.flags & PassiveStaticEffect)
(current.flags & StaticMaskEffect) !==
(workInProgress.flags & StaticMaskEffect)
) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@acdlite mentioned a concern that we might not be resetting static flags correctly. This DEV check has been expanded to also cover the static layout and ref flags.

Comment on lines +2409 to +2375
if (
enableSuspenseLayoutEffectSemantics &&
isModernRoot &&
offscreenSubtreeWasHidden &&
!offscreenSubtreeIsHidden
) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've verified in the built bundle that DCE works to correctly strip these conditional branches when enableSuspenseLayoutEffectSemantics is false.

@bvaughn bvaughn force-pushed the suspense-layout-effects branch from aaaa8e5 to 9563aad Compare March 29, 2021 16:28
@bvaughn
Copy link
Contributor Author

bvaughn commented Mar 29, 2021

The failing ReactLazy-test.internal.js revealed a new scenario I need to add a case to ReactSuspenseEffectsSemantics for.

  • Add new test

@bvaughn bvaughn force-pushed the suspense-layout-effects branch 2 times, most recently from 58a403b to d9be7b5 Compare March 30, 2021 02:15
@bvaughn
Copy link
Contributor Author

bvaughn commented Mar 30, 2021

I think everything passes now except the Suspense fuzz test, which caught a problem that I need to dig into:

<React.Suspense
  fallback="Loading..."
> 
  <React.Suspense>
    <React.Suspense>
      <Text
        initialDelay={9683}
        text="E"
        updates={[]}
      />
    </React.Suspense>
    <Text
      initialDelay={4053}
      text="C"
      updates={
        [
          {
            "beginAfter": 1566,
            "suspendFor": 4142,
          },
          {
            "beginAfter": 9572,
            "suspendFor": 4832,
          },
        ]
      }
    />
  </React.Suspense>
</React.Suspense>
);

The variant yields "E:0C:1" when the test expects "E:0C:2". I'll dig in tomorrow.

Looking closer at this, the difference is related to this semantic change. The legacy root output and effects match (because the new semantics only apply to modern roots) but the modern root varies: when a certain subtree is hidden (because it suspends in an update), its layout effects are destroyed and not recreated. In the legacy branch, layout effects are created an additional time.

Not yet sure if this indicates a problem with my implementation or just an expected observable difference.

@bvaughn bvaughn force-pushed the suspense-layout-effects branch 2 times, most recently from 786c2c9 to 1ad6bb7 Compare March 30, 2021 02:47
@bvaughn
Copy link
Contributor Author

bvaughn commented Mar 30, 2021

Digging into the above failing test case further. The behavior of both control group and sync legacy render match. (New semantics aren't enabled for legacy roots.) In both groups we only create layout effects once.

In the final batch of ReactNoop.createRoot().render() work though, the behavior differs. When the subtree suspends in an update, and gets hidden, the new branch destroys the layout effect but the old branch doesn't. This means that the second, larger beginAfter timeout is able to fire before the end of the test which increments the state an additional time.

@bvaughn bvaughn marked this pull request as ready for review March 30, 2021 15:03
@bvaughn bvaughn changed the title [draft] Proposed new Suspense layout effect semantics Proposed new Suspense layout effect semantics Mar 30, 2021
@bvaughn bvaughn force-pushed the suspense-layout-effects branch 5 times, most recently from ec2d1ff to 7e40b76 Compare March 31, 2021 02:27
This was referenced Nov 6, 2024
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.

6 participants