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
While looking into adding the "no-nested-ternary" ESLint rule, I realized that
this logic could be refactored a bit.
This nested ternary was introduced in pull request #3875 in order to handle
falsy returns from `parse()`.
This refactor avoids the nested ternary and also makes the intent clearer by
associating the empty array directly with `parse()`'s return.
It also more narrowly handles the falsy case (we never intended to allow you
call `set(0)` for example.)
The only down side I can see is that if `parse()` returns falsy, we will
unnecessarily slice/clone the empty array we just created.
This is only enabled as a warning, since in some cases I think it adds clarity.
I left the "gratuitous parentheses" when they were clarifying nested ternary
operators or clarifying the evaluation order of `&&`s and `||`s.
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.
