-
Notifications
You must be signed in to change notification settings - Fork 47.2k
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
Don't count the time inside flushes towards lifecycle hooks #6860
Conversation
Fixes #6842. We keep the existing behavior of testing for matching `onBeginLifeCycleTimer`/`onEndLifeCycleTimer` calls, but we push the current timer onto the stack if we enter a flush. This solves an issue with portals which cause updates while a lifecycle timer is already running. I chose to subtract the time spent in the flush from the time counted towards the lifecycle method because it would artificially inflate the “total” time of the component due to all the components inside the portal, so it would skew the exclusive table.
// - in the nested flush, we call it twice before and after <Foo /> rendering. (n = 3) | ||
// - we capture the time when we exit a nested flush (n = 4) | ||
// - we capture the time we exit componentDidMount (n = 5) | ||
// Time spent in componentDidMount = (5 - 0 - (4 - 3)) = 4. |
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.
Not super happy about this. If it’s too brittle, I can probably do something nasty like call ReactDOM.render()
100 times and assert that the lifecycle own time is smaller than the inner element’s render time.
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.
This works for me.
Sending this one your way too @spicyj 😄 |
// This is how we get 4 as a number with the performanceNow() mock: | ||
// - we capture the time we enter componentDidMount (n = 0) | ||
// - we capture the time when we enter a nested flush (n = 1) | ||
// - in the nested flush, we call it twice before and after <Foo /> rendering. (n = 3) |
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.
nit: add a comma after "twice" or else it sounds like it's called twice before and twice after
@gaearon updated the pull request. |
…#6860) * Don't count the time inside flushes towards lifecycle hooks Fixes facebook#6842. We keep the existing behavior of testing for matching `onBeginLifeCycleTimer`/`onEndLifeCycleTimer` calls, but we push the current timer onto the stack if we enter a flush. This solves an issue with portals which cause updates while a lifecycle timer is already running. I chose to subtract the time spent in the flush from the time counted towards the lifecycle method because it would artificially inflate the “total” time of the component due to all the components inside the portal, so it would skew the exclusive table. * Fix up the comment (cherry picked from commit 8d7161e)
* Don't count the time inside flushes towards lifecycle hooks Fixes #6842. We keep the existing behavior of testing for matching `onBeginLifeCycleTimer`/`onEndLifeCycleTimer` calls, but we push the current timer onto the stack if we enter a flush. This solves an issue with portals which cause updates while a lifecycle timer is already running. I chose to subtract the time spent in the flush from the time counted towards the lifecycle method because it would artificially inflate the “total” time of the component due to all the components inside the portal, so it would skew the exclusive table. * Fix up the comment (cherry picked from commit 8d7161e)
Fixes #6842.
We keep the existing behavior of testing for matching
onBeginLifeCycleTimer
/onEndLifeCycleTimer
calls, but we push the current timer onto the stack if we enter a flush. This solves an issue with portals which cause updates while a lifecycle timer is already running.I chose to subtract the time spent in the flush from the time counted towards the lifecycle method because it would artificially inflate the “total” time of the component due to all the components inside the portal, so it would skew the exclusive table.