This repository was archived by the owner on Apr 12, 2024. It is now read-only.
fix(ngRepeat): fix trackBy function being invoked with incorrect scope - #16777
Merged
Conversation
gkalpak
approved these changes
Nov 29, 2018
Member
|
For future reference, this was broken in bdd853c. |
jbedard
force-pushed
the
16776
branch
2 times, most recently
from
November 29, 2018 19:09
0070020 to
5819a21
Compare
jbedard
added a commit
to jbedard/angular.js
that referenced
this pull request
Nov 29, 2018
This also fixes a leak of that scope across all further instances of the repeated element. Fixes angular#16776 Closes angular#16777
jbedard
commented
Nov 29, 2018
jbedard
added a commit
to jbedard/angular.js
that referenced
this pull request
Nov 30, 2018
Also fixes a leak of that scope across all further instances of the repeated element. Fixes angular#16776 Closes angular#16777
jbedard
commented
Nov 30, 2018
|
|
||
| // Clear the value property from the hashFnLocals object to prevent a reference to the last value | ||
| // being leaked into this ngRepeatCompile function scope | ||
| hashFnLocals[valueIdentifier] = undefined; |
Contributor
Author
There was a problem hiding this comment.
WDYT about clearing the value here? This way we don't have to touch the trackByIdExpFn method that gets invoked on each element and just add this one assignment at the end.
gkalpak
reviewed
Nov 30, 2018
| // Clear the value property from the hashFnLocals object to prevent a reference to the last value | ||
| // being leaked into this ngRepeatCompile function scope | ||
| if (hashFnLocals) { | ||
| hashFnLocals[valueIdentifier] = undefined; |
Member
There was a problem hiding this comment.
What about keyIdentifier? Can't is be non-primitive?
Contributor
Author
There was a problem hiding this comment.
The keyIdentifier value is either an index or the itemKey from for (var itemKey in collection). So it should always be a number or string.
Contributor
Author
|
The build is all green 😲 |
Narretz
approved these changes
Dec 5, 2018
Also fixes a leak of that scope across all further instances of the repeated element. Fixes angular#16776 Closes angular#16777
Contributor
Author
|
I rebased just to add "Ref #16776" to the second commit message, and got the build green again! |
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
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.
This also fixes a leak of that scope across all further instances of the
repeated element.
Fixes #16776
What is the current behavior? (You can also link to an open issue here)
The track-by function would get created on the first linking of an
ng-repeatand then get cached forever, so each time thatng-repeatwas re-linked (when it is repeated, or destroyed+recreated viang-ifetc.) the previous scope would be used. This also "leaks" the scope for the lifetime of that compiled node.What is the new behavior (if this is a feature change)?
The track-by no longer directly references the scope