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

Fix bug when fatal error is thrown as a result of batch.commit #12480

Merged
merged 1 commit into from
Mar 29, 2018

Conversation

acdlite
Copy link
Collaborator

@acdlite acdlite commented Mar 29, 2018

Fixes #12474

Copy link
Collaborator

@gaearon gaearon left a comment

Choose a reason for hiding this comment

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

Seems okay.

Can you give me a rough explanation of the top-level flow these days? I'm not sure how nextFlushedRoot, nextFlushedExpirationTime, nextRoot, nextRenderExpirationTime, and root's expirationTime interact now.

@acdlite
Copy link
Collaborator Author

acdlite commented Mar 29, 2018

It's a bit awkward because we're thinking we might lift the root scheduling stuff at the bottom (performWork and all that) into the renderers. Or at least one level higher. That way renderers like React Native have the option of using a different root scheduler than the one used by React DOM.

That's why you see this duplication of nextFlushed<Thing> vs next<Thing>. It's an artifact of the separation between the renderer and scheduler. The ones with flush in the name conceptually belong to the renderer.

General flow is

  • setState fires requestWork, which adds a root to the root schedule and schedules a callback (performAsyncWork) with requestIdleCallback.
  • performAsyncWork calls performWork, which loops through the list of roots and starts working on them in order of priority.
  • performWorkOnRoot calls the render phase and commit phase as separate entry points. This way, a renderer has the option to defer the commit phase until later. That's how createBatch works. Before, the commit phase would always fire right after the render phase, so there was less control.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants