fix(cdk-experimental/column-resize): Ensure resizable entity is not d… #24007
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…estroyed before applying min/max update The styleSchedule.scheduleEnd() function will sometimes call the provided callback after the nativeElement has been destroyed. The width of this nativeElement is used in the _apply(Min/Max)WidthPx functions to calculate a width diff. If the nativeElement has already been destroyed, the "current" width of the element is 0 so the column effectively doubles in width even though it technically didn't change. This width change is propagated up to the table which increases its size to account for the increased column width. If the element has been destroyed, we can just ignore any resize logic pertaining to that old column since it should no longer affect the table's width. A newer version of that entity should make the change if necessary.
google-cla
bot
added
the
cla: yes
kseamon
added
area: material/table
G
|
Changes LGTM. Is it possible to capture this in a unit test? |
|
I don't think a unit test is possible unless we have some mechanism to mock the styleScheduler (which I don't see). Otherwise we can't effectively control when the scheduleEnd() callback will be called. |
crisbeto
added
action: merge
kseamon
approved these changes
Nov 29, 2021
wagnermaciel
pushed a commit
that referenced
this pull request
Dec 3, 2021
…estroyed before applying min/max update (#24007) The styleSchedule.scheduleEnd() function will sometimes call the provided callback after the nativeElement has been destroyed. The width of this nativeElement is used in the _apply(Min/Max)WidthPx functions to calculate a width diff. If the nativeElement has already been destroyed, the "current" width of the element is 0 so the column effectively doubles in width even though it technically didn't change. This width change is propagated up to the table which increases its size to account for the increased column width. If the element has been destroyed, we can just ignore any resize logic pertaining to that old column since it should no longer affect the table's width. A newer version of that entity should make the change if necessary. (cherry picked from commit 35cdf7c)
This was referenced Jan 1, 2022
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…estroyed before applying min/max update
The styleSchedule.scheduleEnd() function will sometimes call the provided callback after the nativeElement has been destroyed. The width of this nativeElement is used in the _apply(Min/Max)WidthPx functions to calculate a width diff. If the nativeElement has already been destroyed, the "current" width of the element is 0 so the column effectively doubles in width even though it technically didn't change. This width change is propagated up to the table which increases its size to account for the increased column width.
If the element has been destroyed, we can just ignore any resize logic pertaining to that old column since it should no longer affect the table's width. A newer version of that entity should make the change if necessary.
See internal ticket b/207484257 for before/after screenshots of this change.