3 ms·
"Most importantly, Backbone events have two new methods: listenTo and stopListening... When you destroy Views with view.remove(), this will now be done automati
by marcusestes 14y ago
"Most importantly, Backbone events have two new methods: listenTo and stopListening... When you destroy Views with view.remove(), this will now be done automatically"
Well that seems incredibly useful.
- philfreo 14y agoThis was added in December with 0.9.9 - but yes, it's very useful :)
- masklinn 14y agoIn fact, all but the last 2 items on the list are from 0.9.9: http://backbonejs.org/#changelog http://backbonejs.org/#changelog
- mcrider 14y agoWait, so in previous versions, when you destroy a view, event listeners weren't destroyed? I haven't noticed any issues in my Backbone app but this seems like it could spiral into a memory issue.
- ricardobeat 14y agoYes, this is (was?) a long standing problem, they are called "zombie events". Here's a famous post on the issue: http://lostechies.com/derickbailey/2011/09/15/zombies-run-managing-page-transitions-in-backbone-apps/ http://lostechies.com/derickbailey/2011/09/15/zombies-run-ma...
- playhard 14y agoYes. The event listeners were not removed with currentView.remove(). Had to use currentView.unbind() to remove the event listeners.
- jashkenas 14y agoThose were added in 0.9.9, and yes -- they might be useful. If your app tends to have views and models be created and destroyed together on the same cycle, then you don't need to ever `stopListening`. Garbage collection just works as it should. The new-ish methods are handy when your models live longer then your views do. Because this inversion tracks the listeners on the object that's listening to events, instead of the object that's emitting them, it makes it easier to unbind all of the things a view is listening to, when you want to remove just that view. To that end, `view.remove()` stops listening automatically.