Add "track-by" capability

[jtrussell]

Use case:

Some selected items leave your list (they're filtered away, paged away, etc.) then are later added back but the re-added items are are not the same (===) as the old ones, maybe they came from a fresh call to the server and your object references are broken. We'd like to recognize the re-added items as selected even though they're actually different objects.

This might be tricky since we allow programmatic changes to the selected property and the collection items themselves are considered the "master record" of selected states.

[dylaninvodo]

We're having to clean up our selected items due to this limitation. I'd love to be able to configure a property to check for equality.

[jtrussell]

Just curious, what do you mean by clean up selected items?

I've been hesitant to add this feature because one reflection I couldn't think of a use for it that didn't create a coupling with the view. I'd be interested to hear your use case.

[dylaninvodo]

Well, I've refactored my code quite a bit in the last week but the use case was as you originally described.

• We get a list of items from the server and display them in the UI.
  • Stored as $scope.items
  • The total list is 200 items long
  • Using infinite-scrolling, we only return a 'page' of items
  • $scope.items currently holds the first 25 items
• User selects the first 5 items
• User clicks list header to re-sort items
  • A different sub-set of 25 items are shown. None of the selected items are in $scope.items now
• User clicks the same heading to return to original sort order

At this point, I can't remember the exact behavior but I believe either the originally selected items were not reselected at all, OR they were reselected but the count of selected items was now 10. It appears that angular-selection-model uses === under the hood. My request would be a configurable property name to check equality based on (eg; item.id)

[jtrussell]

That's interesting I think the directive should behave as expected assuming you have the entire list loaded on the front end. If your infinite scrolling implementation fetches from the server (and discards previously fetched items as they're scrolled out of view) then you're right you would have to do some extra work to keep things in sync.

The issue is I think we'd have to end up keeping a master list of the selected items whereas now the collection itself holds that information. So I think it'd be a pretty significant shift in how the directive behaves.

I'd be open to implementation suggestions and pull requests provided they don't introduce any additional coupling with the view (i.e. dependence on digest cycles to maintain model consistency).