V2: Model events during "remove" do not trigger on Col #3806
Conversation
|
That makes perfect sense. You really don't think this should be merged? |
|
Not now, it's a breaking change. I figure if this many people are causing an infinite loop in the "remove" event, they're also relying on event bubbling. |
|
The |
|
Yes. |
|
|
||
| if (!options.silent) { | ||
| options.index = index; | ||
| model.trigger('remove', model, this, options); | ||
| this._onModelEvent('remove', model, this, options); |
There was a problem hiding this comment.
Why call _onModelEvent here? We know it will bypass all of the conditionals because we don't specifically handle remove.
There was a problem hiding this comment.
Since it could be overridden. We're not exactly clear on what is overridable and what's not. #3703
There was a problem hiding this comment.
:eyeroll:
The ones that are meant to be overridden are usually obvious, or their
utility becomes clear when you need them. They don't get in your way if you
don't need them.
I can't think of a reason why you'd override _onModelEvent. It seems to be
there mostly to make it easier to unbind later.
Theres no issue using _onModelEvent but I like the symmetry of the two
triggers in a row.
jridgewell
changed the title
DO NOT MERGE, BREAKING CHANGE This is for the next major, v2.
On the heels of #3803, this prevents events triggered on the model during the "remove" event listener from bubbling up to the collection.
Why? Because the model is "removed" from the collection. You can't
#getit any more, there're no more references. The collection shouldn't know anything about the model once that event is fired.