class syntax

When Ember was birthed in the early 2010s (first as “SproutCore 2” and then “Amber.js” and finally “Ember.js”), the JavaScript world was a remarkably different place. The current pace of change year to year is nothing short of astounding for any language, but doubly so for one that sat languishing for so long. When Ember came around, something like today’s class syntax was unimaginable, and so essentially every framework had its own class system of some sort. Over the past few years, with the proposal and standardization of the class syntax as nice sugar for JavaScript’s prototypal inheritance, the need for a custom object and inheritance model has essentially gone away entirely. However, Ember doesn’t do breaking changes to its API just because; we as a community and the core team in particular have chosen to place a high priority on backwards compatibility. So any adoption of ES6 classes had to work in such a way that we got it without making everyone rewrite their code from scratch.

All of this impacts our story with TypeScript because, well, TypeScript for a long time couldn’t even begin to handle this kind of complexity (it’s a lot for a static type system to be able to express, given how very dynamic the types here can be). As of TS 2.3, it can express most of this object model, which is great… but it’s forever out of step with the rest of the JS/TS ecosystem, which is not so great. ES6 classes are first-class items in TypeScript and the support for getting types right within them is much, much stronger than the support for the mixin/extension style object model Ember currently uses. So moving over to ES6 classes will make it much easier for TS to do the work of telling you you’re doing it wrong with that class—and most importantly, it’ll be able to do that automatically, without needing the incredibly hairy type definition files that we’re still trying to write to get Ember’s current model represented. It Will Just Work. That means less maintenance work and fewer places for bugs to creep in.

Gladly, we’re getting there! Already today, in the most recent versions of Ember, you can write this, and it will work:

import Component from '@ember/component';

export default class MyComponent extends Component {
  theAnswer = 42;
  andTheQuestionIs =
    "What is the meaning of life, the universe, and everything?";
}

When I say “it will work,” I mean you can then turn around and write this in your my-component.hbs and it’ll be exactly what you would expect from the old Ember.Component.extend() approach:

{{andTheQuestionIs}} {{the Answer}}

There is one serious limitation of that today: you can’t do that with a class you need to extend further. So if, for example, you do like we do and customize the application route rinstance and then reuse that in a couple places, you’ll still have to use the old syntax:

import Route from '@ember/route';

export default Route.extend({
  // your customizations...
});

But everywhere you consume that, you can use the new declaration:

import ApplicationRoute from 'my-app/routes/application';

export default class JustSomeRoute extends ApplicationRoute {
  model() {
    // etc.
  }
}

There’s more work afoot here, too, to make it so that these restrictions can go away entirely… but those changes will undoubtedly be covered in considerable detail on the official Ember blog when they roll out.

Decorators

Now, that’s all well and good, but it doesn’t necessarily help with this scenario:

import Component from '@ember/component';
import { computed, get } from '@ember/object';

export default class MyComponent extends Component {
  someProperty = 'is just a string';

  someOtherProperty = computed('someProperty', function() {
    const someProperty = get(this, 'someProperty');
    return someProperty + ' and now I have appended to it';
  });
}

We’re back in the same spot of having unreliable types there. And again: some really careful work writing type definitions to make sure that computed and get both play nicely together with the class definition would help somewhat, but… well, it’d be nice if the types could just be determined automatically by TypeScript. (Also, there’s an open bug on the TypeScript repository for trying to deal with computed; suffice it to say that computed as it currently stands is a sufficiently complicated thing that even with all the incredible type machinery TS 2.1, 2.2, and 2.3 have brought to bear on exactly these kinds of problems… it still can’t actually model computed correctly.)

For several years now, Rob Jackson has maintained [a small library] that let you write computed properties with decorators. Up till recently, those were incompatible with TypeScript, because they used to work in the context of object literals rather than classes—and TypeScript never supported that. However, as of about a month ago as I’m writing this, they’ve been updated and they do work with ES6 classes. So, given the class syntax discussed above, you can now ember install ember-decorators and then do this:

import Component from '@ember/component';
import { computed } from 'ember-decorators/object';

export default class MyComponent extends Component {
  someProperty = 'with a string value';

  @computed('someProperty')
  someOther(someProperty: string) {
    return someProperty + ' that you can append to';
  }
}

Here, we can provide a type on the parameter to someOther, which at a minimum makes this enormously cleaner and less repetitive syntactically. More interestingly, however, we should (though no one has done it just yet, to my knowledge) be able to write a type definition for @computed such that TypeScript will already know that someProperty here is a string, because it’ll have the context of the class in which it’s operating. So that example will be even simpler:

import Component from '@ember/component';
import { computed } from 'ember-decorators/object';

export default class MyComponent extends Component {
  someProperty = 'with a string value';

  @computed('someProperty')
  someOther(someProperty) {
    return someProperty + ' that you can append to';
  }
}

And in that imagined, wonderful future world, if we tried to do something that isn’t a valid string operation—say, we tried someProperty / 3—TypeScript would complain to us, loudly.

Although this is still a future plan, rather than a present reality, it’s not that far off. We just need someone to write that type definition for the decorators, and we’ll be off to the races wherever we’re using the new ES6 class approach instead of the existing Ember.Object approach. So: soon. I don’t know how soon, but soon.