1. Default values

Since class property setup runs during the constructor, if you want the caller to be able to override it, you must give it an explicit fallback that references what’s passed into the function. Something like this:

class AnyClass {
  aDefaultProp = this.aDefaultProp || 0;
}

Again, translated back into the constructor form:

class AnyClass {
  constructor() {
    this.aDefaultProp = this.aDefaultProp || 0;
  }
}

Here, you can see that if something has already set the aDefaultProp value (before the class constructor is called), we’ll use that value; otherwise, we’ll use the default. You can think of this as being something like default arguments to a function. In our codebase, we have started using _.defaultTo, which works quite nicely. In the old world of declaring props with their values in the .extends({ ... }) hash, we got this behavior “for free”—but without a lot of other benefits of classes, so not actually for free.

2. No more shared state

Because these are instance properties, not assigned on the prototype, you do not have to worry about the problem—well-known among experienced Ember.js developers, but prone to bite people new to the framework—where you assign an array or object in the .extend() method and then find that it’s shared between instances.

export default Component.extend({
  anArray: [],  // <- this *will* be shared between instances
});

We’ve long had to handle this by setting up those properties in our init() method instead, so that they are created during object instantiation, rather than on the prototype. This problem goes away entirely with classes, including in TypeScript.

export default class MyComponent extends Component {
  anArray = [];  // <- this will *not* be shared between instances
}

(Note that here, we don’t have a type for the array, so it’s of type any[]; we always need type annotations for empty arrays if we want them to be a “narrower,” or more specific, type than that.)

3. Performance changes

The flip-side of this is that the only way we currently have to create computed property instances (until decorators stabilize) is also as instance, not prototype, properties. I’ll look at computed properties (and their types) in more detail in the next post, so here mostly just note how the computed is set up on the class: by assignment, not as a prototypal property.

export default class MyComponent extends Component {
  aString = 'Hello, there!';

  itsLength = computed('aString', function(this: MyComponent): number {
    return this.aString.length;
  });
}

This does have a performance cost, which will be negligible in the ordinary case but pretty nasty if you’re rendering hundreds to thousands of these items onto the page. You can use this workaround for these as well as for any other properties which need to be prototypal (more on that in the next post as well):²

export default class MyComponent extends Component.extend({
  itsLength: computed('aString', function(this: MyComponent): number {
      return this.aString.length;
    }
  );
}) {
  aString = 'Hello, there!';
}

This looks really weird, but it works exactly as you’d expect.

Variant 1: Prototypal/merged properties

The first is when you’re using properties that need to be merged with properties in the prototype chain, e.g. attributeBindings or classNameBindings, or which (because of details of how components are constructed) have to be set on the prototype rather than as instance properties, e.g. tagClass.

For those, we can just leverage .extend in conjunction with classes:

import Component from '@ember/component';

export default class MyListItem extends Component.extend({
  tagName: 'li',
  classNameBindings: ['itemClass']
}) {
  itemClass = 'this-be-a-list';

  // etc.
}

This is also how you’ll use mixins (on defining them, see below):

import Component from '@ember/component';
import MyMixin from 'my-app/mixins/my-mixin';

export default class AnExample extends Component.extend(MyMixin) {
  // the rest of the definition.
}

Note, however—and this is very important—that you cannot .extend an existing class implementation. As a result, deep inheritance hierarchies may make transitioning to classes in Ember painful. Most importantly: they may work some of the time in some ways, but will break when you least expect. So don’t do that! (This isn’t a TypeScript limitation; it’s a limitation of classes in Ember today.)³

Variant 2: Mixins

The other time you’ll have to take a different tack—and this falls directly out of the need for prototypal merging—is with Mixins, which don’t yet work properly with classes. Worse, it’s difficult (if not impossible) to get rigorous type-checking internally in Mixin definitions, because you cannot define them as classes: you have to use the old style throughout, because mixins are created with .create(), not .extend().

I’ll have a lot more to say about these in part 5 of this series, including a detailed example of how to carefully type-annotate one and use it in another class. For now, suffice it to say that you’ll still need to incorporate Mixins via .extend():

import Component from '@ember/component';
import MyMixin from 'my-app/mixins/my-mixin';

export default class SomeNewComponent extends Component.extend(MyMixin) {
  // normal class properties
}