You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In previous versions, when model was removed from collection, you first cleaned up the index (this._byId), and only then you trigger remove event. Which was okay.
In 1.2, you first remove the model, trigger remove, and only then clean up the index in _removeReference. Thus, in the remove event handler model is still present in the index (while absent in collection), resulting in successful get. Which leads to weird things, like infinite loop when trying to remove the same model again in 'remove' event handler.
Is there any specific reason you now triggering 'remove' while collection is in inconsistent state, or it's just a bug?
Thanks for invitation. Quite recently I have decided that I don't need dependency from backbone in my framework any more. I would rather have my own implementation of collections. Have fun with tickets.
In previous versions, when model was removed from collection, you first cleaned up the index (
this._byId
), and only then you triggerremove
event. Which was okay.In 1.2, you first remove the model, trigger
remove
, and only then clean up the index in_removeReference
. Thus, in theremove
event handler model is still present in the index (while absent in collection), resulting in successfulget
. Which leads to weird things, like infinite loop when trying to remove the same model again in 'remove' event handler.Is there any specific reason you now triggering 'remove' while collection is in inconsistent state, or it's just a bug?
The text was updated successfully, but these errors were encountered: