OSSForks/react
1
0
Fork 0
mirror of https://github.com/zebrajr/react.git synced 2026-01-15 12:15:22 +00:00
Code Issues Actions 6 Packages Projects Releases Wiki Activity

Decrease expiration time of input updates (#19772)

Browse Source 
Changes the expiration time of input updates from 1000ms to 250ms, to
match the corresponding constant in Scheduler.js.

When we made it larger, a product metric in www regressed, suggesting
there's a user interaction that's being starved by a series of
synchronous updates. If that theory is correct, the proper solution is
to fix the starvation. However, this scenario supports the idea that
expiration times are an important safeguard when starvation does happen.

Also note that, in the case of user input specifically, this will soon
no longer be an issue because we plan to make user input synchronous by
default (until you enter `startTransition`, of course.)

If weren't planning to make these updates synchronous soon anyway, I
would probably make this number a configurable parameter.
This commit is contained in:
Andrew Clark
2020-09-04 12:42:09 -05:00
committed by GitHub
parent 36df483af4
commit 708fa77a78
1 changed files with 15 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
packages/react-reconciler/src/ReactFiberLane.js vendored
View File

@@ -384,7 +384,21 @@ function computeExpirationTime(lane: Lane, currentTime: number) {
const priority = return_highestLanePriority;
if (priority >= InputContinuousLanePriority) {
// User interactions should expire slightly more quickly.
return currentTime + 1000;
//
// NOTE: This is set to the corresponding constant as in Scheduler.js. When
// we made it larger, a product metric in www regressed, suggesting there's
// a user interaction that's being starved by a series of synchronous
// updates. If that theory is correct, the proper solution is to fix the
// starvation. However, this scenario supports the idea that expiration
// times are an important safeguard when starvation does happen.
//
// Also note that, in the case of user input specifically, this will soon no
// longer be an issue because we plan to make user input synchronous by
// default (until you enter `startTransition`, of course.)
//
// If weren't planning to make these updates synchronous soon anyway, I
// would probably make this number a configurable parameter.
return currentTime + 250;
} else if (priority >= TransitionPriority) {
return currentTime + 5000;
} else {