A number of projects at Pivotal have been using Backbone.js to build single page web apps. I’ve enjoyed using Backbone: it’s lightweight, unopinionated, helps encourage good separation of concerns between models and views, and reduces a fair bit of JavaScript boilerplate by bringing just enough framework to the table.

Unfortunately, it’s very easy to write Backbone code that leaks – especially in the view layer. A common backbone pattern is to set up some event bindings for a view:

var MyView = Backbone.View.extend({
    initialize: function() {
        this.model.on('change', this.update, this);
        this.someOtherModel.on('change', this.update, this);
        this.boundResizeHandler = _.bind(this.resizeHandler, this);
        $(window).on('resize', this.boundResizeHandler);
    },
    ...etc..
});

If your app needs to switch between several such views it is not enough to simply remove the view’s DOM and null out any references to the view. You must also unbind these event bindings in order for the view to be garbage collected. Moreover, if this view contains any subviews, you must also tear down all event bindings for all its subviews. If you do not succesfully clear out all bindings the view (and/or its subviews) will leak.

What’s worse: while there are some great tools out there to identify leaking objects, Backbone’s default constructor lists all objects as type child. This makes finding the leaky Backbone objects that are instances of MyView nearly impossible in Chrome’s heap propfiler.

Coccyx attempts to adress these problems by doing two things:

1. Coccyx adds named constructors to Backbone. You no longer need to wonder which child is yours. By adding constructorName when you extend a Backbone class you’ll be able to easily tell which object is which in the console and the heap profiler.

2. Coccyx implements teardown-able view hierarchies. You can easily build view hierarchies in which parents are aware of their children and can tear the entire structure down by calling tearDown() on a root node. tearDown() automatically unbinds any Backbone event bindings, cleans up DOM events and gives your view a chance to perform any custom teardown via a callback.

There are many more details at https://github.com/onsi/coccyx. Bug reports and pull requests are encouraged!

Inheritance in Backbone

Backbone.js comes with a minimalist OO inheritance framework similar to the one employed by CoffeeScript. Each base class has a static method called extend that is used to create a subclass, like this:

User = Backbone.Model.extend({
  // instance methods
},
{
  // class methods
});

extend returns a constructor whose prototype inherits from Backbone.Model.prototype. References to all of Backbone.Model’s static methods and properties (including extend) are copied to the new constructor.

Calling ‘super’

The constructor also receives a __super__ property, which references its superclass.

User.__super__ === Backbone.Model.prototype

This makes it possible to call super inside of a class or and instance method:

User.prototype.save = function(attrs) {
    this.beforeSave(attrs);
    User.__super__.save.apply(this, arguments);
};

CoffeeScript has a super keyword that compiles to the line above, but when using Backbone with plain javascript, its a little grating to have to type that out.

A small layer of convenience

I wrote this little super method (test-driven using jasmine) which saves me having to repeat the constructor’s name all over the place. You call it like this:

User.prototype.save = function(attrs) {
    this.beforeSave(attrs);
    this._super("save", arguments);
};

The second parameter to _super is the array of arguments to pass to the overridden method. This is to optimize for the common case of passing the arguments object straight through.

There’s no way to avoid having to repeat the method name like that, unless you wrap every method definition with a helper function that either passes the overridden method as a parameter (a la Prototype.js) or reassigns a hidden super property behind the scenes (like JS.Class or John Resig’s approach). These approaches won’t work with Backbone’s ultra-minimalist inheritance system.