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

Resume immediately pinged fiber without unwinding #25074

Merged
merged 4 commits into from
Aug 12, 2022
Merged

Resume immediately pinged fiber without unwinding #25074

merged 4 commits into from
Aug 12, 2022

Commits on Aug 10, 2022

  1. Yield to main thread if continuation is returned 

    Instead of using an imperative method `requestYield` to ask Scheduler to
yield to the main thread, we can assume that any time a Scheduler task
returns a continuation callback, it's because it wants to yield to the
main thread. We can assume the task already checked some condition that
caused it to return a continuation, so we don't need to do any
additional checks — we can immediately yield and schedule a new task
for the continuation.

The replaces the `requestYield` API that I added in ca990e9.
    @acdlite
    acdlite committed Aug 10, 2022
    Configuration menu
    Copy the full SHA
    fbb94d3 View commit details
    Browse the repository at this point in the history

  2. Move unwind after error into main work loop 

    I need to be able to yield to the main thread in between when an error
is thrown and when the stack is unwound. (This is the motivation behind
the refactor, but it isn't implemented in this commit.) Currently the
unwind is inlined directly into `handleError`.

Instead, I've moved the unwind logic into the main work loop. At the
very beginning of the function, we check to see if the work-in-progress
is in a "suspended" state — that is, whether it needs to be unwound. If
it is, we will enter the unwind phase instead of the begin phase.

We only need to perform this check when we first enter the work loop:
at the beginning of a Scheduler chunk, or after something throws. We
don't need to perform it after every unit of work.
    @acdlite
    acdlite committed Aug 10, 2022
    Configuration menu
    Copy the full SHA
    2eac58a View commit details
    Browse the repository at this point in the history

  3. Yield to main thread whenever a fiber suspends 

    When a fiber suspends, we should yield to the main thread in case the
data is already cached, to unblock a potential ping event.

By itself, this commit isn't useful because we don't do anything special
in the case where to do receive an immediate ping event. I've split this
out only to demonstrate that it doesn't break any existing behavior.

See the next commit for full context and motivation.
    @acdlite
    acdlite committed Aug 10, 2022
    Configuration menu
    Copy the full SHA
    438ce50 View commit details
    Browse the repository at this point in the history

  4. Resume immediately pinged fiber without unwinding 

    If a fiber suspends, and is pinged immediately in a microtask (or a
regular task that fires before React resumes rendering), try rendering
the same fiber again without unwinding the stack. This can be super
helpful when working with promises and async-await, because even if the
outermost promise hasn't been cached before, the underlying data may
have been preloaded. In many cases, we can continue rendering
immediately without having to show a fallback.

This optimization should work during any concurrent (time-sliced)
render. It doesn't work during discrete updates because those are
semantically required to finish synchronously — those get the current
behavior.
    @acdlite
    acdlite committed Aug 10, 2022
    Configuration menu
    Copy the full SHA
    eefdb73 View commit details
    Browse the repository at this point in the history