-
Notifications
You must be signed in to change notification settings - Fork 27.4k
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
1 similar comment
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
I signed it! |
CLAs look good, thanks! |
1 similar comment
CLAs look good, thanks! |
src/ng/directive/ngRepeat.js
Outdated
* will not be updated even when the corresponding item changes, essentially causing the view to get | ||
* out-of-sync with the underlying data. | ||
* {@link guide/expression#one-time-binding one-time bindings} or {@link guide/directive#creating-directives directives}. | ||
* In such cases, where the array changes and `track by $index` is in use the `nth` DOM element |
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 doesn't look like it specifies what you mean, coz this works fine: https://plnkr.co/edit/dxzgjmE5MEA0bwQdckVS?p=preview aswell as https://plnkr.co/edit/2i0WKKzh1uDlj4kOrBFN?p=preview
Even tho I'm changing the array.
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.
https://plnkr.co/edit/ytQ9p6YJOfrDubCGIc2N?p=preview
Click the remove and you will see the the UI is not updated and that the fail becomes green.
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.
I know, it just that making a simple change to ur plunkr solves the issue: https://plnkr.co/edit/d39OLmANDGv8EuxXxA6k?p=preview (I replaced splice
with slice
)
Hence it's not very clear that this is the problem with arrays. (basicly I guess it's immutable vs changing the existing array)
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.
Interesting, what does $filter use? As this is what we are using that causes this issue.
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.
$filter
uses Array.prototype.filter
, which also doesn't manipulate the array but instead returns a new array. See: https://github.com/angular/angular.js/blob/master/src/ng/filter/filter.js#L172
Messed up the commit messages, unsure what the process is to fix this. (not going to use the git cli unless specified as the documentation does not say what to do if missed)
|
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the |
1 similar comment
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the |
@michael-letcher I pulled down your branch, squashed the commits and force-pushed back to your branch. This has the effect of updating this PR. |
Clarify the pitfalls of using `track by $index` Closes #16332
This reads as if it's fine to use in all other situations. Despite the fact I agree Theoretically, it'll bring in a performance boost. Practically it's not something you want to be using, right ? Wouldn't it be more beneficial to focus on tracking by something useful instead? To be fair, what's to be said of |
@frederikprijck I agree, should I change the documentation to reflect this? @gkalpak Also mentioned this:
|
@michael-letcher - please do update to reflect this. You will need to pull down the latest commits from your branch before you try to make changes, since I pushed to your branch when I squashed.
This should update everything locally (and there should be a message about how the branch had been force pushed). Then when you have made the change be sure to amend the current commit, in the terminal you would use |
track by $index is perfectly usable when you have only simple interpolation / expressions in the template, but not one-time bindings, or directives - all content that is static. I agree that we should only mention track by $index at the end of the section, with all the current and extra caveats. At the moment, we lead with it, which is bad. |
@Narretz I read this often, yet I added working plunkers with https://plnkr.co/edit/dxzgjmE5MEA0bwQdckVS?p=preview
It's usable, but doesn't make alot of sense to track by an index in an array in most cases.
Ye, and focus on alternatives, like tracking by a property (even tho that doesn't have to be part of this PR I guess) |
@michael-letcher I just changed one line in the docs in the past. If you need my consent for this change, I'll give it to you. Should I need to do anything more? |
@franciscovelez I think @michael-letcher mistakenly |
@Narretz I did, whoops! I'll review the documentation again, and perhaps reorder the notion of track by to clearly state what Angular will be doing with it e.g. keep func. that is what gives the performance boost and not mention that using $index gives the benefit. |
🤔 It make sense hahaha |
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.
Technically, the re-using of elements can also have an impact when using track by 'unique id'.
See https://plnkr.co/edit/24fcSM9h2AzgVvSt9ef4?p=preview
If you click "update" then you can see that for John 2, "fail" changes to "pass", but the directive is not re-compiled (the status color does not change) and the one-time binding is not updated.
track by $index only adds a special case: when you remove item 0, ngRepeat re-uses element 0, but with item 1's scope.
(If you use track by 'unique id', then ngRepeat re-uses element 1)
I wonder if we can make this clearer in the docs?
* will not be updated even when the corresponding item changes, essentially causing the view to get | ||
* out-of-sync with the underlying data. | ||
* {@link guide/expression#one-time-binding one-time bindings} or {@link guide/directive#creating-directives directives}. | ||
* In such cases, where the array changes and `track by $index` is in use the `nth` DOM element |
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.
where ...
-> when ..
in use the
-> in use, the
* will always be matched with the `nth` item of the array. Since ngRepeat thinks that this item is the same as before, | ||
* it will not re-create the DOM, but keep the existing one (bound to the existing scope), and therefore | ||
* any directives that appear on the template will not be re-compiled (since compilation/linking happens only when a new instance is created). | ||
* This is ngRepeats "keep track" function at play and it to reduce unnecessary DOM elements being rebuilt. |
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.
I don't think this last sentence adds useful info.
* In such cases, where the array changes and `track by $index` is in use the `nth` DOM element | ||
* will always be matched with the `nth` item of the array. Since ngRepeat thinks that this item is the same as before, | ||
* it will not re-create the DOM, but keep the existing one (bound to the existing scope), and therefore | ||
* any directives that appear on the template will not be re-compiled (since compilation/linking happens only when a new instance is created). |
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.
Please keep this line at 100 characters
- deduplicate info between docs section and arguments - don't draw too much attention to track by ... - ... but highlight its drawbacks when used with one-time bindings - add example to show how tracking affects collection updates - clarify duplicates support for specific tracking expressions Closes angular#16332 Closes angular#16334
- deduplicate info between docs section and arguments - don't draw too much attention to track by $index ... - ... but highlight its drawbacks - add example to show how tracking affects collection updates - clarify duplicates support for specific tracking expressions Closes #16332 Closes #16334 Closes #16397
- deduplicate info between docs section and arguments - don't draw too much attention to track by $index ... - ... but highlight its drawbacks - add example to show how tracking affects collection updates - clarify duplicates support for specific tracking expressions Closes angular#16332 Closes angular#16334 Closes angular#16397
- deduplicate info between docs section and arguments - don't draw too much attention to track by $index ... - ... but highlight its drawbacks - add example to show how tracking affects collection updates - clarify duplicates support for specific tracking expressions Closes #16332 Closes #16334 Closes #16397
Updating docs to be more clear about the pitfalls of track by $index
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Documentation Update
What is the current behavior? (You can also link to an open issue here)
NA
What is the new behavior (if this is a feature change)?
NA
Does this PR introduce a breaking change?
No
Please check if the PR fulfills these requirements
Other information:
REF #16332