Fixes#3882Fixes#4159
Backbone does a bit of extra work to determine when to update `_byId` on every model change event because `change:id` will not work if `idAttribute` has changed. This causes issues as the `change` event happens after every `change:` event which means during a change the `_byId` hasn't updated. Rather than adding complexity to collection the solution is to have the model notify with the id changes.
If adding a public event isn't desired, for an internal solution the model is aware of it's collection and could modify model.collection._byId directly within the set.
Either of these solutions seem preferrable to handling `change:[idAttribute]`
Replaces the need for:
https://github.com/jashkenas/backbone/pull/4227/files#diff-c773bb9be277f0f3f2baa308b6e0f3a486790fe99fea81ddd0ba409846250571R1205
This introduces new methods related to Iterators on Backbone.Collection to mirror those found on Array: `values`, `keys`, `entries`, and `@@iterator`. Each of these methods will return a JavaScript Iterator, which has a `next` method, yielding the models or ids of models contained in the Collection.
The CollectionIterator is careful to use the `at()` and `modelId()` methods on the host collection rather than direct access to the `models` property, which should ensure it is resilient to creative subclassing of Backbone.Collection and future feature addition.
The [`@@iterator`](http://www.ecma-international.org/ecma-262/6.0/#sec-well-known-symbols) method is defined using `Symbol.iterator` if it exists in the JavaScript runtime (modern browsers/node.js) and falls back to the string `"@@iterator"` which was popularized by older versions of Firefox and has become the standard fallback behavior for other third-party libraries. This ensures that Backbone can still be used across all browsers, even with use of these new methods.
Supporting Iterable allows better integration between Backbone and the most recent additions to the JavaScript language, including `for of` loops and data-collection constructor functions, as well as better integration with other third-party libraries that accept Iterables instead of only Arrays.
Fixes#3954
- modelId now takes the model in question as the second argument
- modelId will look at the model in question's idAttribute before falling back to Collection.prototype.model.modelId and then 'id'
- Makes basic polymorphic collection work out of the box while retaining backwards compatability
In an attempt to bring our ESLint rules closer to those in Underscore, I've
started by adding some whitespace rules which don't involve any significantly
opinionated changes.
The documented example shows passing `[]` to instantiate an empty collection
while still supplying an options object. This change makes the preceding
documentation consistent with that example.
I also noticed that we don't have any tests covering the previously recommended
approach of passing `null` (or any falsey value) for models. I've added a test
to ensure we continue to support that usage.
Fixes#3693.
This leaves open the question of whether events triggered on the model
during a ‘remove’ listener should also trigger on the model. Just
something to revisit for V2.
```js
col.on('other', (model) => {
// Should this be triggered?
});
col.on('remove', (model) => {
// If the model is really "removed" (we can't `#get` it anymore)
// by the time this listener is called, then I'd argue that this
// shouldn't trigger the 'other' event on the collection...
model.trigger('other');
});
```
