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.

Sign up for GitHub

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

Jump to bottom

Track entangled lanes separately from update lane #27505

Merged
merged 2 commits into from
Oct 15, 2023
Merged

Track entangled lanes separately from update lane #27505

merged 2 commits into from
Oct 15, 2023

Commits on Oct 12, 2023

  1. Clarify desired behavior of test case 

    I updated one of the tests related to synchronous popstate transitions
to clarify what the desired behavior is. It's really about what happens
if a popstate transition suspends. It should not cause an error, and
the transition should be allowed to finish once the promise resolves.

Ideally, if the transition suspends, it should completely revert back
to the default behavior for transitions — i.e. it should no longer be
treated as synchronous. Currently we don't do that, and when the promise
resolve the transition will still be rendered synchronously, but we can
improve this later.
    @acdlite
    acdlite committed Oct 12, 2023
    Configuration menu
    Copy the full SHA
    18e7d91 View commit details
    Browse the repository at this point in the history

  2. Track entangled lanes separately from update lane 

    A small refactor to how the lane entanglement mechanism works. We can
now distinguish between the lane that "spawned" a render task (i.e. a
new update) versus the lanes that it's entangled with. Both the update
lane and the entangled lanes will be included while rendering, but
by keeping them separate, we don't lose the original priority.

In practical terms, this means we can now entangle a low priority update
with a higher priority lane while rendering at the lower priority.

To do this, lanes that are entangled at the root are now tracked using
the same variable that we use to track the "base lanes" when revealing
a previously hidden tree — conceptually, they are the same thing. I
also renamed this variable (from subtreeLanes to entangledRenderLanes)
to better reflect how it's used.

My primary motivation is related to useDeferredValue, which I'll address
in a later PR.
    @acdlite
    acdlite committed Oct 12, 2023
    Configuration menu
    Copy the full SHA
    717595f View commit details
    Browse the repository at this point in the history