-
Notifications
You must be signed in to change notification settings - Fork 2.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
[Table] Introduce TableBodyCells component to avoid unnecessary cell renders #1596
Conversation
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.
To be clear: mostly, all you did was made a different separation of concerns for rendering cells vs rendering regions, right? So that changing regions doesn't re-render cells? (which is a boat load of work)
Looks good to me!
Hmm, will look into this after lunch. |
Fix testsPreview: documentation | table |
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.
Preview looks good. All those unnecessary renders cut!
Merge branch 'master' into cl/table-body-cells-componentPreview: documentation | table |
Addresses #1547
Checklist
Include tests(no need; just an under-the-hood refactor)Changes proposed in this pull request:
Before:
TableBody
used to invokeprops.renderCell
for every cell in view, every timeselectedRegions
changed, just to run a diff against the currently rendered cells. That's a lot of wasted work for an interaction that doesn't affect the cells themselves.After:
TableBodyCells
component now encapsulates all cell rendering and doesn't respond toselectedRegions
changes. This means that we now do zero work in theTableBody
when that prop changes. Woo!shouldComponentUpdate
logic inTableBody
.Reviewers should focus on:
selectedRegions
change anymore.Screenshot