Ember Data

There remains one significant challenges to using Ember Data effectively with TypeScript today: Ember Data, for reasons I haven’t yet dug into myself, does not play nicely with ES6 classes. However, we need named class exports for the sake of being able to use them as types elsewhere in our programs. The hack to work around this is much the same as anywhere else we need named exports but have to get things back into the prototype:

import DS from "ember-data";

export default class Person extends DS.Model.extend({
  firstName: DS.attr("string"),
  lastName: DS.attr("string")
}) {}

You can still define other items of the class normally, but attributes have to be prototypally bound or you will have problems. Note that this only applies (as far as I can tell) to Ember Data Models specifically—Adapter and Serializer classes work just fine.

The other problem we’ve historically had was dealing with lookups—the situation was similar to that I described in Part 3 for service injection. However, as of this week, we’re landing a solution that means you can drop the type coercions and just do a lookup like you would normally, and it will Just Work™️.¹ Keep your eyes open for the ember-cli-typescript 1.1 release in the next couple days!

Once this release of both ember-cli-typescript and the updated typings land, when you generate an Ember Data model by doing ember generate model person firstName:string lastName:string, it will look like this:

import DS from "ember-data";

export default class Person extends DS.Model.extend({
  firstName: DS.attr("string"),
  lastName: DS.attr("string")
}) {
  // normal class body definition here
}

// DO NOT DELETE: this is how TypeScript knows how to look up your models.
declare module "ember-data" {
  interface ModelRegistry {
    person: Person;
  }
}

That module and interface declaration at the bottom merges the declaration for this model with the declarations for all the other models. You’ll see the same basic pattern for DS.Adapter and DS.Serializer instances. The result is that using a model will now look like this. In addition to the Person model definition just above, our adapter might be like this:

import DS from "ember-data";

export default class Person extends DS.Adapter {
  update(changes: { firstName?: string; lastName?: string }) {
    fetch("the-url-to-change-it", {
      method: "POST",
      body: JSON.stringify(changes)
    });
  }
}

declare module "ember-data" {
  interface ModelRegistry {
    person: Person;
  }
}

Then putting the pieces together, our component definition will just look like this:

import Component from "@ember/component";
import { inject as service } from "@ember/service";

export default class PersonCard extends Component {
  id: string | number;

  store = service("store");
  model = this.store.findRecord("person", this.id);

  actions = {
    savePerson(changes: { firstName?: string; lastName?: string }) {
      this.store.adapterFor("person").update(changes);
    }
  };
}

The type of model here is now Person & DS.PromiseObject<Person> (which is actually what Ember Data returns for these kinds of things!), and the this.store.adapterFor actually correctly returns the Person adapter as well, so the call to its update method type-checks as well (including guaranteeing that the arguments to it are correct). That also means you’ll get autocompletion for those, including for their types, if you’re using an editor configured for it. And, happily for everyone, if you mistype a string (preson instead of person, for example), you’ll get a compile-time error!

Notice as well that the service injection is much cleaner than it was in earlier examples in the series. That’s because we made the same “registry”-type changes—as I suggested we might back in Part 1!—for controller and service injections. Before, for this kind of thing:

export default class PersonCard extends Component {
  store: Computed<DS.Store> = service();
}

Now:

export default class PersonCard extends Component {
  store = service("store");
}

That’s not quite as minimalist as what you get in vanilla Ember (where the name of the property is used to do the lookup at runtime), but it’s pretty close, and a huge improvement! Not least since it’s exactly as type-checked, and therefore as friendly to autocomplete/IntelliSense/etc. as it was before.

import DS from "ember-data";

export default class Person extends DS.Model.extend({
  firstName: DS.attr("string"),
  lastName: DS.attr("string")
}) {}

import DS from "ember-data";

export default class Person extends DS.Model.extend({
  firstName: DS.attr("string"),
  lastName: DS.attr("string")
}) {}

declare module "ember-data" {
  interface ModelRegistry {
    person: Person;
  }
}

import DS from "ember-data";

export default class Person extends DS.Adapter {
  // customization
}

import DS from "ember-data";

export default class Person extends DS.Adapter {
  // customization
}

declare module "ember-data" {
  interface AdapterRegistry {
    person: Person;
  }
}

import DS from "ember-data";

export default class Person extends DS.Serializer {
  // customization
}

import DS from "ember-data";

export default class Person extends DS.Serializer {
  // customization
}

declare module "ember-data" {
  interface SerializerRegistry {
    person: Person;
  }
}

import Service from "@ember/service";

export default class ExternalLogging extends Service {
  // implementation
}

import Service from "@ember/service";

export default class ExternalLogging extends Service {
  // implementation
}

declare module "ember" {
  interface ServiceRegistry {
    "external-logging": ExternalLogging;
  }
}

import Controller from "@ember/controller";

export default class Profile extends Controller {
  // implementation
}

import Controller from "@ember/controller";

export default class Profile extends Controller {
  // implementation
}

declare module "@ember/controller" {
  interface ControllerRegistry {
    profile: Profile;
  }
}

declare module "ember-data" {
  interface ModelRegistry {
    [key: string]: DS.Model;
  }
}

  import Component from '@ember/component';
  import { inject as service } from '@ember/service';
- import Computed from '@ember/object/computed';
-
- import ExternalLogging from 'my-app/services/external-logging';

  export default class UserProfile extends Component {
-   externalLogging: Computed<ExternalLogging> = service();
+   externalLogging = service('external-logging');
    // other implementation
  }

const person = this.store.findRecord<Person>("person", 123);

const person = this.store.findRecord("person", 123);

type Loaded<T> = T & DS.PromiseObject<T>;
const person: Loaded<Person> = this.store.findRecord("person", 123);

import Component from "@ember/component";

export default class PersonDisplay extends Component {
  model: Loaded<Person>; // instead of just `model: Person`
}

Conclusion

And that’s pretty much a wrap on Ember Data! The next post you can expect in this series will be a break from nitty-gritty “how to use TS in Ember” posts for a very exciting, closely related announcement—probably tomorrow or Monday! The post after that will be a deep dive into (mostly the limitations of!) writing types for mixins and proxies.