Component arguments

export default class AnExample extends Component {
  // Component arguments
  model: Person;      // required
  modifier?: string;  // optional, thus the `?`

I always put these first so that the “interface” of the object is clear and obvious. You can do the same thing on a controller instance; in that case you would export a Model from the corresponding Route class and import it into the Controller. It’s a bit of boilerplate, to be sure, but it lets you communicate your interface clearly to consumers of the Component or Controller.

An important note about these kind of arguments: you do not have to do this.get(...) (or, if you prefer, get(this, ...)) to access the properties themselves: they’re class instance properties. You can simply access them as normal properties: this.model, this.modifier, etc. That even goes for referencing them as computed properties, as we’ll see below.

For optional arguments, you use the ? operator to indicate they may be undefined. To get the most mileage out of this, you’ll want to enable strictNullChecks in the compiler options.¹ However, note that we don’t currently have any way to validate component argument invocation.[^ts-templates] The way I’ve been doing this is using Ember’s debug assert in the constructor:

assert("`model` is required", !isNone(this.model));

import Component from "@ember/component";
import { Maybe } from "true-myth";

export default class MyComponent extends Component {
  optionalArg?: string;
  optionalProperty = Maybe.of(this.optionalArg);
}

Then if you invoke the property without the argument, it’ll construct a Nothing; if you invoke it with the argument, it’ll be Just with the value. [^ts-templates]: A few of us have batted around some ideas for how to solve that particular problem, but if we manage those, it’ll probably be way, way later in 2018.

Edit, January 24, 2018: Starting in TypeScript 2.7, you can enable a flag, --strictPropertyInitialization, which requires that all declared, non-optional properties on a class be initialized in the constructor or with a class property assignment. (There’s more on class property assignment in part 2 of this series.) If you do that, all arguments to a component should be defined with the definite assignment assertion modifier, a ! after the name of the property, as on model here:

export default class AnExample extends Component {
  // Component arguments
  model!: Person;     // required
  modifier?: string;  // optional, thus the `?`

You should still combine that with use of assert so that any misses in template invocation will get caught in your tests.

Injections

  // -- Injections -- //
  session: Computed<Session> = service();

Here, the most important thing to note is the required type annotation. In principle, we could work around this by requiring you to explicitly name the service and using a “type registry” to look up what the service type is – more on that below in my discussion of using Ember Data – but I’m not yet persuaded that’s better than just writing the appropriate type annotation. Either way, there’s some duplication. 🤔 We (everyone working in the typed-ember project) would welcome feedback here, because the one thing we can’t do is get the proper type without one or the other of these.

Edit, February 5, 2018: see Part 4 for some updates to this—I actually went ahead and built and implemented that approach, and everything is much nicer now.

  // the current approach -- requires importing `Session` so you can define it
  // on the property here
  session: Computed<Session> = service();

  // the alternative approach I've considered -- requires writing boilerplate
  // elsewhere, similar to what you'll see below in the Ember Data section
  session = service('session');

One other thing to notice here is that because TypeScript is a structural type system, it doesn’t matter if what is injected is the actual Session service; it just needs to be something that matches the shape of the service – so your normal behavior around dependency injection, etc. is all still as expected.

That’s enough for one post, I think. In the next entry, we’ll pick up with how you handle class properties, including computed properties, and then talk about mixins as well. In the post after that, we’ll look at Ember Data and some related concerns.