[Scheduler] Test browser implementation details #16198
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Scheduler implementation uses browser APIs like `MessageChannel`, `requestAnimationFrame`, and `setTimeout` to schedule work on the main thread. Most of our tests treat these as implementation details; however, the sequence and timing of these APIs are not precisely specified, and can vary wildly across browsers. To prevent regressions, we need the ability to simulate specific edge cases that we may encounter in various browsers. This adds a new test suite that mocks all browser methods used in our implementation. It assumes as little as possible about the order and timing of events. The only thing it assumes is that requestAnimationFrame is passed a frame time that is equal to or less than the time returned by performance.now. Everything else can be controlled at will. It also includes Scheduler-specific invariants, e.g. only one rAF callback can be scheduled at a time. It overlaps slightly with the existing SchedulerDOM-test suite, which also mocks the browser APIs, but exposes a higher-level set of testing primitives. I will consolidate the two suites in a follow-up.
acdlite
commented
Jul 25, 2019
| prevRAFTime !== -1 && | ||
| // Make sure this rAF time is different from the previous one. This check | ||
| // could fail if two rAFs fire in the same frame. | ||
| rAFTime - prevRAFTime > 0.1 |
There was a problem hiding this comment.
This particular change fixes a bug in Safari where we post a rAF from inside another rAF, and that rAF fires within the same frame. One of the tests I added covers this scenario.
|
React: size: -0.0%, gzip: -0.0% Details of bundled changes.Comparing: 19354db...8c1adfa react
scheduler
Generated by 🚫 dangerJS |
acdlite
force-pushed
the
scheduler-browser
branch
from
f0b0bcd
to
8c1adfa
Compare
bvaughn
approved these changes
Jul 25, 2019
| currentTime = targetTime; | ||
| } | ||
| } | ||
| function getMostRecentFrameNumber() { |
There was a problem hiding this comment.
trivial naming nit: getCurrentFrameNumber? "Most recent" feels like an odd name to use when currentTime is exactly at a frame boundary.
Edit I see how you're using this method in the tests below, and getMostRecentFrameNumber makes more sense as a name. I think the usage in fireAnimationFrame feels more like a "current" value but I don't feel strongly about this. 😄
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Scheduler implementation uses browser APIs like
MessageChannel,requestAnimationFrame, andsetTimeoutto schedule work on the main thread. Most of our tests treat these as implementation details; however, the sequence and timing of these APIs are not precisely specified, and can vary wildly across browsers.To prevent regressions, we need the ability to simulate specific edge cases that we may encounter in various browsers.
This adds a new test suite that mocks all browser methods used in our implementation. It assumes as little as possible about the order and timing of events. The only thing it assumes is that requestAnimationFrame is passed a frame time that is equal to or less than the time returned by performance.now. Everything else can be controlled at will.
It also includes Scheduler-specific invariants, e.g. only one rAF callback can be scheduled at a time.
It overlaps slightly with the existing SchedulerDOM-test suite, which also mocks the browser APIs, but exposes a higher-level set of testing primitives. I will consolidate the two suites in a follow-up.