Preventing memory leaks in Backbone.js
paydirtapp.com
Preventing memory leaks in Backbone.js
1–10 of 36 posts
Re: Preventing memory leaks in Backbone.js
#2Don't nested child views get garbage collected when the root view is removed?
Re: Preventing memory leaks in Backbone.js
#3Don't nested child views get garbage collected when the root view is removed?
If the parent is the only place where there's a reference to the child view, then yes. However like the article says, you often have things like event listeners that, if the child view doesn't clean up, will prevent the child view from getting collected. (And often, the listeners still do stuff causing buggy behavior.)
This is fixed by ensuring there's an off()/unbind() for every on()/bind(). I do this by following a pattern like the one in this article: http://lostechies.com/derickbailey/2011/09/15/zombies-run-ma...
Re: Preventing memory leaks in Backbone.js
#4Don't nested child views get garbage collected when the root view is removed?
If the parent is the only place where there's a reference to the child view, then yes. However like the article says, you often have things like event listeners that, if the child view doesn't clean up, will prevent the child view from getting collected. (And often, the listeners still do stuff causing buggy behavior.) This is fixed by ensuring there's an off()/unbind() for every on()/bind(). I do this by following a…
Yes, but if they are bound to the child's element and that is removed shouldn't that be sufficient unless the view is binding to other elements or window events?
Re: Preventing memory leaks in Backbone.js
#5Ugh. Examples use Coffeescript instead of universally accessible Javascript. Looks very useful though; I've just started learning about Backbone, and the lack of a "right way of doing things" is disconcerting, coming from a lot of Rails usage lately. It takes me back to the days of doing a lot of stuff by hand.
Even without that uncertainty, it's definitely a bit tricky to move to thinking about everything being in the browser.
Re: Preventing memory leaks in Backbone.js
#6Earlier quoted context omitted.
If the parent is the only place where there's a reference to the child view, then yes. However like the article says, you often have things like event listeners that, if the child view doesn't clean up, will prevent the child view from getting collected. (And often, the listeners still do stuff causing buggy behavior.) This is fixed by ensuring there's an off()/unbind() for every on()/bind(). I do this by following a…
Yes, but if they are bound to the child's element and that is removed shouldn't that be sufficient unless the view is binding to other elements or window events?
Backbone Views often bind to model/collection events.
Re: Preventing memory leaks in Backbone.js
#7Earlier quoted context omitted.
If the parent is the only place where there's a reference to the child view, then yes. However like the article says, you often have things like event listeners that, if the child view doesn't clean up, will prevent the child view from getting collected. (And often, the listeners still do stuff causing buggy behavior.) This is fixed by ensuring there's an off()/unbind() for every on()/bind(). I do this by following a…
Yes, but if they are bound to the child's element and that is removed shouldn't that be sufficient unless the view is binding to other elements or window events?
It's quite common to bind to events on objects like models or collections etc. which will not be unbound just because the dom element is.
Re: Preventing memory leaks in Backbone.js
#8Two things you can do together to help, but need Backbone edge version (master) for the second, at the moment:
1. myModel.on('change:title', this.render, this); // inside `myView`
2. myView.dispose(); // when you are done with `myView`
Re: Preventing memory leaks in Backbone.js
#9AFAIR, it's one of the issues Backbone.Marionette is trying to fix with its bindTo/close solution.
Re: Preventing memory leaks in Backbone.js
#10Earlier quoted context omitted.
Yes, but if they are bound to the child's element and that is removed shouldn't that be sufficient unless the view is binding to other elements or window events?
It's quite common to bind to events on objects like models or collections etc. which will not be unbound just because the dom element is.
Isn't that true only for older Internet Explorer versions because they had two garbage collectors, one for DOM stuff and one for JScript stuff?