From 708fa77a783bbe729cfcebdd513d23eafc455b8b Mon Sep 17 00:00:00 2001 From: Andrew Clark Date: Fri, 4 Sep 2020 12:42:09 -0500 Subject: [PATCH] Decrease expiration time of input updates (#19772) 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. --- packages/react-reconciler/src/ReactFiberLane.js | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/packages/react-reconciler/src/ReactFiberLane.js b/packages/react-reconciler/src/ReactFiberLane.js index 8e6a66f9210a8..3dc89c45a9561 100644 --- a/packages/react-reconciler/src/ReactFiberLane.js +++ b/packages/react-reconciler/src/ReactFiberLane.js @@ -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 {