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

Remove LanePriority from computeExpirationTime #21087

Merged
merged 1 commit into from
Mar 25, 2021
Merged

Remove LanePriority from computeExpirationTime #21087

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 52 additions & 25 deletions packages/react-reconciler/src/ReactFiberLane.new.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -428,31 +428,58 @@ export function getMostRecentEventTime(root: FiberRoot, lanes: Lanes): number {
}

function computeExpirationTime(lane: Lane, currentTime: number) {
// TODO: Expiration heuristic is constant per lane, so could use a map.
getHighestPriorityLanes(lane);
const priority = return_highestLanePriority;
if (priority >= InputContinuousLanePriority) {
// User interactions should expire slightly more quickly.
//
// 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 {
// Anything idle priority or lower should never expire.
return NoTimestamp;
switch (lane) {
case SyncLane:
case InputContinuousHydrationLane:
case InputContinuousLane:
// User interactions should expire slightly more quickly.
//
// 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.
return currentTime + 250;
case DefaultHydrationLane:
case DefaultLane:
case TransitionHydrationLane:
case TransitionLane1:
case TransitionLane2:
case TransitionLane3:
case TransitionLane4:
case TransitionLane5:
case TransitionLane6:
case TransitionLane7:
case TransitionLane8:
case TransitionLane9:
case TransitionLane10:
case TransitionLane11:
case TransitionLane12:
case TransitionLane13:
case TransitionLane14:
case TransitionLane15:
case TransitionLane16:
case RetryLane1:
case RetryLane2:
case RetryLane3:
case RetryLane4:
case RetryLane5:
return currentTime + 5000;
case SelectiveHydrationLane:
case IdleHydrationLane:
case IdleLane:
case OffscreenLane:
// Anything idle priority or lower should never expire.
return NoTimestamp;
default:
Copy link
Member

Choose a reason for hiding this comment

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

Can also add (type: empty); here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm not opposed but it's a bigger change because I'd need to make the Lane an enum which will affect the bit trickery we do elsewhere.

if (__DEV__) {
console.error(
'Should have found matching lanes. This is a bug in React.',
);
}
return NoTimestamp;
}
}

Expand Down
77 changes: 52 additions & 25 deletions packages/react-reconciler/src/ReactFiberLane.old.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -428,31 +428,58 @@ export function getMostRecentEventTime(root: FiberRoot, lanes: Lanes): number {
}

function computeExpirationTime(lane: Lane, currentTime: number) {
// TODO: Expiration heuristic is constant per lane, so could use a map.
getHighestPriorityLanes(lane);
const priority = return_highestLanePriority;
if (priority >= InputContinuousLanePriority) {
// User interactions should expire slightly more quickly.
//
// 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 {
// Anything idle priority or lower should never expire.
return NoTimestamp;
switch (lane) {
case SyncLane:
case InputContinuousHydrationLane:
case InputContinuousLane:
// User interactions should expire slightly more quickly.
//
// 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.
return currentTime + 250;
case DefaultHydrationLane:
case DefaultLane:
case TransitionHydrationLane:
case TransitionLane1:
case TransitionLane2:
case TransitionLane3:
case TransitionLane4:
case TransitionLane5:
case TransitionLane6:
case TransitionLane7:
case TransitionLane8:
case TransitionLane9:
case TransitionLane10:
case TransitionLane11:
case TransitionLane12:
case TransitionLane13:
case TransitionLane14:
case TransitionLane15:
case TransitionLane16:
case RetryLane1:
case RetryLane2:
case RetryLane3:
case RetryLane4:
case RetryLane5:
return currentTime + 5000;
case SelectiveHydrationLane:
case IdleHydrationLane:
case IdleLane:
case OffscreenLane:
// Anything idle priority or lower should never expire.
return NoTimestamp;
default:
if (__DEV__) {
console.error(
'Should have found matching lanes. This is a bug in React.',
);
}
return NoTimestamp;
}
}

Expand Down