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

[Bugfix] Passive effects triggered by synchronous renders in a multi-root app #17347

Merged
merged 2 commits into from
Nov 12, 2019

Commits on Nov 11, 2019

  1. Configuration menu
    Copy the full SHA
    772a01b View commit details
    Browse the repository at this point in the history

Commits on Nov 12, 2019

  1. [Bugfix] Passive effects loop

    The bug
    -------
    
    In a multi-root app, certain passive effects (`useEffect`) are never
    fired. See facebook#17066.
    
    The underlying problem
    ----------------------
    
    The implicit contract of `flushPassiveEffects` is that, right after
    calling it, there should be no pending passive effects. In the normal
    case, in concurrent mode, this is true. But the current implementation
    fails to account for the case where a passive effect schedules
    synchronous work, which in turn schedules additional passive effects.
    
    This led to `rootWithPendingPassiveEffects` being overwritten in the
    commit phase, because an assignment that assumed it was replacing null
    was actually replacing a reference to another root, which has the
    consequence of dropping passive effects on that root.
    
    The fix
    -------
    
    The fix I've chosen here is, at the beginning of the commit phase, keep
    flushing passive effects in a loop until there are no more.
    
    This doesn't not change the "public" implementation of
    `flushPassiveEffects`, though it arguably should work this way, too. I
    say "public" because it's only used by implementation layers on top of
    React which we control: mainly, the legacy version of `act` that does
    not use the mock Scheduler build. So there's probably still a bug
    in that `act` implementation.
    
    I will address `act` in a follow-up. The ideal solution is to replace
    the legacy `act` with one implemented directly in the renderer, using a
    special testing-only build of React DOM. Since that requires a breaking
    change, we'll need an interim solution. We could make the "public" `act`
    recursively flush effects in a loop, as I've done for the commit phase.
    However, I think a better solution is to stop automatically flushing the
    synchronous update queue at the end of `flushPassiveEffects`, and
    instead require the caller to explicitly call `flushSyncUpdateQueue` (or
    the equivalent) if needed. This follows the same pattern we use
    internally in the work loop, which is designed to avoid factoring
    hazards like the one that resulted in this bug.
    acdlite committed Nov 12, 2019
    Configuration menu
    Copy the full SHA
    c386a55 View commit details
    Browse the repository at this point in the history