Computed properties

We already covered component arguments and injections as well as basic class properties and the exceptions to normal class-property ways of doing things, in Parts 1 and 2. With that background out of the way, we can now turn to computed properties. I’m including the component arguments in this code sample because they’re referenced in the computed property. Assume Person is a pretty “person” representation, with a firstName and a lastNameand maybe a few other properties.

  // -- Component arguments -- //
  model: Person;      // required
  modifier?: string;  // optional, thus the `?`

  // -- Computed properties -- //
  // TS correctly infers computed property types when the callback has a
  // return type annotation.
  fromModel = computed(
    'model.firstName',
    function(this: AnExample): string {
      return `My name is ${get(this.model, 'firstName')};`;
    }
  );

  aComputed = computed('aString', function(this: AnExample): number {
    return this.lookAString.length;
  });

  isLoggedIn = bool('session.user');
  savedUser: Computed<Person> = alias('session.user');

export default class MyComponent extends Component.extend({
  fromModel: computed(
    'model.firstName',
    function(this: AnExample): string {
      return `My name is ${get(this.model, 'firstName')};`;
    }
  ),
}) {
  // other properties
}

// type checking error:
this.fromModel.length;

// type checking valid:
this.get('fromModel').length;

  isLoggedIn = bool('session.user');
  savedUser: Computed<Person> = alias('session.user');

const foo = {
  ['some.nested.key']: 'Well, this is weird, but it works',
};

Actions

What about actions? As usual, these just become class instance properties in the current scheme.

  actions = {
    addToCollection(this: AnExample, value: string) {
      const current = this.get('aCollection');
      this.set('aCollection', current.concat(value));
    }
  };

As with computed properties, we need the this type declaration to tell TypeScript that this method is going to be automatically bound to the class instance. Otherwise, TypeScript thinks the this here is the actions hash, rather than the MyComponent class.³

Happily, that’s really all there is to it for actions: they’re quite straightforward other than needing the this type specification.

Types in .extend({...}) blocks

By and large, you can get away with using the same this: MyComponent trick when hacking around prototypal extension problems, or performance problems, by putting computed properties in a .extend({...} block. However, you will sometimes see a type error indicating that the class is referenced in its own definition expression. In that case, you may need to judiciously apply any, if you can’t make it work by using normal class properties.

constructor and class methods

ES6 class constructors and class methods both work as you’d expect, though as we’ll see you’ll need an extra bit of boilerplate for methods, at least for now.

  constructor() {
    super();
    assert('`model` is required', !isNone(this.model));

    this.includeAhoy();
  }

  includeAhoy(this: AnExample): void {
    if (!this.get('aCollection').includes('ahoy')) {
      this.set('aCollection', current.concat('ahoy'));
    }
  }

For the most part, you can just switch to using normal ES6 class constructors instead of the Ember init method. You can, if you so desire, also move existing init functions passed to a .extends({ ...}) hash to class methods, and they’ll work once you change this._super(...arguments) to super.init(...arguments). It’s worth pausing to understand the relationship between init and prototypal init and the constructor. An init in the .extends() hash runs first, then an init method on the class, then the normal constructor.⁴

Note that you do not need to (and cannot) annotate the constructor with this: MyComponent. Depending on the class you’re building, you may occasionally have type-checking problems that come up as a result of this. I’ve only ever seen that happen when using computed properties while defining a proxy,⁵ but it does come up. In that case, you can fall back to using init as a method, and set this: MyComponent on it, and things will generally fall out as working correctly at that point. When it comes up, this seems to be just a limitation of what this is understood to be in a constructor given Ember’s rather more-complex-than-normal-classes view of what a given item being constructed is.

Other class methods do also need the this type specified if they touch computed properties. (Normal property access is fine without it.) That’s because the lookups for ComputedProperty instances (using Ember.get or Ember.set) need to know what this is where they should do the lookup, and the full this context isn’t inferred correctly at present. You can either write that on every invocation of getand set, like (this as MyComponent).get(...), or you can do it once at the start of the method. Again, a bit boiler-platey, but it gets the job done and once you’re used to it it’s minimal hassle.⁶

One last note, which I didn’t include in the example: if you have a function (usually an action) passed into the component, you can define it most simply by just using onSomeAction: Function; in the class definition, right with other class arguments. However, it’s usually most helpful to define what the type should actually be, for your own sanity check if nothing else. As with e.g. model in this example, we don’t actually have a good way to type-check that what is passed is correct. We can, however, at least verify in the constructor that the caller passed in a function using assert, just as with other arguments.