Backbone and ES6 Classes

[benmccormick]

With the final changes to the ES6 class spec (details here), it's no longer possible to use ES6 classes with Backbone without making significant compromises in terms of syntax. I've written a full description of the situation here (make sure to click through to the comments at the bottom for an additional mitigating option), but essentially there is no way to add properties to an instance of a subclass prior to the subclasses parents constructor being run.

So this:

class DocumentRow extends Backbone.View {

    constructor() {
        this.tagName =  "li";
        this.className = "document-row";
        this.events = {
            "click .icon":          "open",
            "click .button.edit":   "openEditDialog",
            "click .button.delete": "destroy"
        };
        super();
    }

    initialize() {
        this.listenTo(this.model, "change", this.render);
    }

    render() {
        //...
    }
}

is no longer valid in the final ES6 spec. Instead you effectively have 3 (not very appealing) options if you want to try to make this work:

Attach all properties as functions

Backbone allows this, but it feels dumb to write something like this:

class DocumentRow extends Backbone.View {

    tagName() { return "li"; }

    className() { return "document-row";}

    events() {
        return {
            "click .icon":          "open",
            "click .button.edit":   "openEditDialog",
            "click .button.delete": "destroy"
        };
    }

    initialize() {
        this.listenTo(this.model, "change", this.render);
    }

    render() {
        //...
    }
}

compared to the current extends syntax

Run the constructor twice

I don't view this as a real option due to the issues it would cause running initialize a second time with different cids, etc.

Pass all properties as default options to the superclass constructor

This was suggested by a commenter on my blog and is probably the most practical current option. It looks something like this:

class MyView extends Backbone.View {
  constructor(options) {
    _.defaults(options, {
      // These options are assigned to the instance by Backbone
      tagName: 'li',
      className: 'document-row',
      events: {
        "click .icon": "open",
        "click .button.edit": "openEditDialog",
        "click .button.delete": "destroy"
      },
      // This option I'll have to assign to the instance myself
      foo: 'bar'
    });


    super(options);


    this.foo = options.foo;
  }
}

Since all of these current options involve clear compromises relative to the current Backbone extends syntax, it would be wonderful if a better solution could be developed. I'm not totally sure what this should look like, but one idea that came to mind while I did the writeup for my blog was the addition of a "properties" function that would output a hash of properties. The constructor could then run that function and add them to the instance prior to the other processing done by the constructor.

[akre54]

Yeah this is definitely a bummer. Thanks for doing the legwork.

I guess moral of the story is don't use ES6 classes with Backbone, at least until static property support lands. Of the fallback options you proposed my preferred solution is defining the strings / objects as return values. A key part of Backbone's API design is in these prototype-shared strings and objects, and it would dirty up the API to require devs to assign each property to the instance in the constructor (not to mention being memory wasteful).

Aside from consistency, is there any reason to use the class keyword with Backbone over extend?

[jridgewell]

Great blog post. I'd been wonder how ES6 and Backbone classes would play together. As for you solutions:

1. Attach all properties as functions: I'm not super opposed to this. It's not as clean as setting the object directly on the prototype, but I've seen a ton of code trip up on mutating prototype objects. This way is immune, which is why I think ES6 chose not to include class properties.
2. Pass all properties as default options: Isn't this how you'd do something in a more classical language? I feel like this is a even less clean solution than the above.
3. Run the constructor twice: Ick.

I guess moral of the story is don't use ES6 classes with Backbone, at least until static property support lands.

Even class properties come after the super() call. 😞

[benmccormick]

Aside from consistency, is there any reason to use the class keyword with Backbone over extend?

I addressed this in the blog post. Practically? No. In theory it would allow Backbone in the long term to reduce code and additional concepts, but realistically its going to be at least a few years before ES6 classes are widely supported on all relevant browsers without transpiling, and the code reduction would be next to nothing.

But don't underrate the consistency aspect. If this becomes "the way" of doing Object Oriented programming in JavaScript (seems likely given the standardization on this from Ember/Angular/React/Typescript/Aurelia etc), Backbone not using it will be an added learning curve for the library relative to other options. Especially for Junior developers. I'm not sure that necessarily merits a change. But it's not just for pedantic "hobgoblin of small minds" consistency.

[lukeasrodgers]

I agree with @akre54 and @jridgewell that the "attach all properties as functions" approach is probably the best of the proposed options. FWIW, I remember that when I was originally learning backbone as a relative js newcomer, I was a bit confused by these "static" properties and how they should be used.

[A]

ES7 will have correct class properties, I guess https://gist.github.com/jeffmo/054df782c05639da2adb

[benmccormick]

The ES7 proposal is just that, a very early community driven proposal. Not at all clear it will actually ever be part of an official spec. Current implementations cause properties to be added to the instance AFTER the constructor runs, so it doesn't help with Backbone. (see jridgewell's link above or try it yourself with Babel 5.0.0)

[akre54]

@jridgewell I was referring to this part of @benmccormick's post:

React Developers have noted the same issues with property initializers that Backbone users encounter. As part of version 0.13 of React, they're supporting a special property initialization syntax for classes, which may eventually be standardized. There's more info on that in this ESDiscuss thread. This standard is still being worked out but an experimental support version is available in Babel 5.0.0. Unfortunately that version defines class properties as being instantiated after the superclass constructor is run, so this doesn't solve Backbone's issues here.

See for example wycats' js-decorators strawman or the original (superseded) harmony classes proposal.

I might suggest that we use getters with class properties:

class Row extends Backbone.View {
  get tagName() { return 'li'; }
}

As an absolute last resort, we could check for instance or static props with a helper a la _.result:

_.instOrStaticVar = function(instance, property) {
  if (instance == null) return void 0;
  var value = instance[property] || instance.constructor[property];
  return _.isFunction(value) ? value.call(instance) : value;
}

[jridgewell]

Yup, but:

Unfortunately that version defines class properties as being instantiated after the superclass constructor is run, so this doesn't solve Backbone's issues here.

So, ES5'd:

// ES6
class View extends Backbone.View {
  tagName = 'li';

  constructor() {
    // Do anything that doesn't touch `this`
    super();
    // Do anything that touches `this`
  }
}

// ES5
function View() {
  // Do anything that doesn't touch `this`
  Backbone.View.apply(this, arguments);

  // Add class properties
  this.tagName = 'li';

  // Do anything that touches `this`
}
View.prototype = _.create(Backbone.View.prototype, {
  constructor: View
});

Our element would still be constructed before we got a change to set the instance variable.

See for example wycats' js-decorators strawman...

Can you explain how the decorators would apply?

I might suggest that we use getters with class properties:

👍. I see that as the same boat as attach all properties as functions. Not as clean as what we currently have, but perfectly acceptable and mutation proof.

As an absolute last resort, we could check for instance or static props with a helper a la _.result:

That could be interesting...

[jamiebuilds]

You could do:

class MyView extends Backbone.View {
  constructor() {
    super({ tagName: 'h1' });
    this.el.textContent = 'Hello World';
  }
}

[jridgewell]

@thejameskyle That's the Pass all properties as default options to the superclass constructor option. 😛

[milesj]

Instead of relying on super() to setup the class, you could simply have an init() function or something.

class DocumentRow extends Backbone.View {

    constructor() {
        super();
        this.tagName =  "li";
        this.className = "document-row";
        this.events = {
            "click .icon":          "open",
            "click .button.edit":   "openEditDialog",
            "click .button.delete": "destroy"
        };
        this.init();
    }

    initialize() {
        this.listenTo(this.model, "change", this.render);
    }

    render() {
        //...
    }
}

[benmccormick]

@milesj hmm? That will error out immediately with the final ES6 class spec

In a derived class, you must call super() before you can use this

Even if it did work you're never actually calling the Backbone constructor and will not get its initialization code.

See this link from my first post: http://www.2ality.com/2015/02/es6-classes-final.html

[jridgewell]

@milesj: The thing is, you have to call super() before setting this.tagName or the like. And, since we ensure an element in the View's constructor, we've already created an element before we'll ever set this.tagName.