Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: facebook/react
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 7b17f7bbf3243c2890cb830902be8ef8b51db3da
Choose a base ref
...
head repository: facebook/react
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: e86bb503db37a8692ce3b95ad3d2dc743e9c5909
Choose a head ref
  • 1 commit
  • 6 files changed
  • 1 contributor

Commits on Nov 17, 2022

  1. Force unwind work loop during selective hydration

    When an update flows into a dehydrated boundary, React cannot apply the
    update until the boundary has finished hydrating. The way this currently
    works is by scheduling a slightly higher priority task on the boundary,
    using a special lane that's reserved only for this purpose. Because
    the task is slightly higher priority, on the next turn of the work loop,
    the Scheduler will force the work loop to yield (i.e. shouldYield starts
    returning `true` because there's a higher priority task).
    
    The downside of this approach is that it only works when time slicing
    is enabled. It doesn't work for synchronous updates, because the
    synchronous work loop does not consult the Scheduler on each iteration.
    
    We plan to add support for selective hydration during synchronous
    updates, too, so we need to model this some other way.
    
    I've added a special internal exception that can be thrown to force the
    work loop to interrupt the work-in-progress tree. Because it's thrown
    from a React-only execution stack, throwing isn't strictly necessary —
    we could instead modify some internal work loop state. But using an
    exception means we don't need to check for this case on every iteration
    of the work loop. So doing it this way moves the check out of the
    fast path.
    
    The ideal implementation wouldn't need to unwind the stack at all — we
    should be able to hydrate the subtree and then apply the update all 
    within a single render phase. This is how we intend to implement it in
    the future, but this requires a refactor to how we handle "stack"
    variables, which are currently pushed to a per-render array. We need to
    make this stack resumable, like how context works in Flight and Fizz.
    acdlite committed Nov 17, 2022
    Configuration menu
    Copy the full SHA
    e86bb50 View commit details
    Browse the repository at this point in the history
Loading