-
Notifications
You must be signed in to change notification settings - Fork 47.5k
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
Inform DevTools of commit priority level #15664
Inform DevTools of commit priority level #15664
Conversation
ReactDOM: size: -0.0%, gzip: -0.0% Details of bundled changes.Comparing: 0bd9b5d...4c5a0e8 react-dom
react-art
react-native-renderer
react-test-renderer
react-reconciler
Generated by 🚫 dangerJS |
a925a01
to
c1e8e2d
Compare
🤔 Looks like importing
|
const currentTime = requestCurrentTime(); | ||
const priorityLevel = inferPriorityFromExpirationTime( | ||
currentTime, | ||
expirationTime, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these be DEV/PROFILE only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. Yeah probably wouldn't hurt!
const priorityLevel = inferPriorityFromExpirationTime( | ||
currentTime, | ||
expirationTime, | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Andrew mentioned maybe we could use getCurrentPriorityLevel()
here rather than inferring the priority level. I don't think the priority level a Fiber was scheduled with will necessarily match the current priority level though. (Maybe I misunderstood his suggestion.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you call getCurrentPriorityLevel
inside commitRoot
(not commitRootImpl
, since that's always run at ImmediatePriority
— it has to be the wrapper) then it will match the priority of the commit, which is not necessarily the same thing as the priority at which something was scheduled because multiple priorities can get batched.
This approach seems fine, though.
It's possible we may eventually track the priority on the update object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems legit
@@ -11,6 +11,10 @@ | |||
|
|||
describe('ReactIncrementalErrorReplay-test', () => { | |||
it('copies all keys when stashing potentially failing work', () => { | |||
// Include a renderer to ensure host config files are properly shimmed. | |||
// Otherwise transient imports may cause an invariant. | |||
require('react-dom'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I landed another PR which needed this fix so you should be able to revert this file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, cool thanks.
e65faef
to
dc7dcdb
Compare
React now informs DevTools of the commit priority level (so the Profiler can display and potentially filter on the info).
Demo