Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
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
Code Cleanup: Enforce Linting Rules & Update UNSAFE_ React Lifecycle Events #559
Code Cleanup: Enforce Linting Rules & Update UNSAFE_ React Lifecycle Events #559
Changes from 1 commit
75b00918d370823049bd1fe03ad7f11bc185f3471ed4d84dc17f90eda77cd1bc31dbaf3d50aff227d0120988a29b55be21241747ceb413fbac0ec93fd954ebe815546ae8ffcc4c56460c5ef6633ca24024533fd7590aa60ecb62e8f634c1dea5143275a88cb68493d262970629b4d16c2cb47a1File filter
Jump to
Refactor UNSAFE_componentWillMount into either constructor or compone…
wlycdgrJun 4, 2020
Member
I don't understand how this data demonstrates that the
componentDidMountrefactor method is faster. It seems like we need to compare theconstructor+componentDidMount+UNSAFE_componentWillMounttotal times before refactor and after each of the two options.IAmThePanJun 11, 2020
Author
Contributor
Update on Timings:
Constructor + componentDidMount took 14.250ms but those 2 functions don't run back to back. If I time the Constructor and componentDidMount separately I get:
constructor runtime after refactor: 0.0139ms
componentDidMount runtime after refactor: 0.070ms.
This is less than the constructor's runtime when refactoring into the constructor and leads to a faster initial render.
These comments are removed from feature/cleanup-cleanup.
wlycdgrJun 11, 2020
Member
That makes sense!
wlycdgrJun 4, 2020
Member
Similar to my comment above, I don't understand how some of this data is relevant to establishing the conclusion. Why isn't it sufficient to compare the runtime for the
constructor-only refactor against the runtime for thecomponentDidMountrefactor?wlycdgrJun 4, 2020
Member
More generally, we should probably remove these notes altogether once we finish the review, yeah?
IAmThePanJun 11, 2020
Author
Contributor
I agree that we should remove these comments. I wanted to leave them in while you all reviewed the PR, but then it got merged before I could take them out. That's why I created the
feature/cleanup-cleanupbranch and PR. They are removed on that branch.IAmThePanJun 11, 2020
•
edited
Author
Contributor
Yes, it was actually only relevant to see that
UNSAFE_componentWillMountwas doing calculations via#updateDbLastUpdatedand that you shouldn't do calculations in the constructor.from https://reactjs.org/docs/react-component.html#constructor:
But I didn't read that until I had already done the timing for all of these refactors, so I kept it in the comments.
And an update on Timing:
I just tested the timing for the refactored constructor and compoentDidMount. I got 0.020ms for the constructor (less than before the refactor) and 0.150ms for componentDidMount. This leads to a fast initial render.
The Refactor Comments are removed in the
feature/cleanup-cleanupbranch and PR.wlycdgrJun 11, 2020
Member
Thank you for the detailed update/explanation & the link. Sounds good!