ember-data typings

[dwickern]

These typings are generated from https://github.com/typed-ember/ember-typings-generator as a starting point. I did some minor cleanup to make the typings compile.

[chriskrycho]

Well, this looks awesome. It'll probably be midweek before I have time to look super closely, but my initial scan looked super promising.

[dwickern]

I haven't really looked at it myself yet. What I have so far is the generator output and some minor cleanup

[dwickern]

I've got a script which scrapes code snippets from the ember guides. I'll start there to make some tests and see how well the typings work.

[dwickern]

I'm going to wait for #1 before I do any meaningful work on this

[dwickern]

Here's a reference for the ember-data module imports:
https://www.emberjs.com/blog/2016/01/12/ember-data-2-3-released.html#toc_importing-modules

Edit: actually those are the deprecated "shims". The proposal for ember-data module imports is emberjs/rfcs#238

[chriskrycho]

I did just a little bit of playing with this tonight, and put together an initial pass on attr and this seems to work pretty well:

import EmberClass from '@ember-typings';
import EmberObject from '@ember/object';

interface AttrOptions<T> {
  defaultValue: T | (() => T);
  [key: string]: any;
}

declare namespace DS {
  function attr(type: 'string', options?: AttrOptions<string>): string;
  function attr(type: 'boolean', options?: AttrOptions<boolean>): boolean;
  function attr(type: 'number', options?: AttrOptions<number>): number;
  function attr(type: 'date', options?: AttrOptions<Date>): Date;
  function attr<T>(options?: AttrOptions<Date>): T;

  interface Model extends EmberObject {}
  const Model: EmberClass<Model>;
}

export default DS;

The built-ins are all there, and it also supports things which aren't built-in:

import DS from 'ember-data';

export default DS.Model.extend({
  aDate: attr('date'),
  aString: attr('string'),
  aNumber: attr('number'),
  aBool: attr('boolean'),
  somethingElse: attr<{ neatThings: string }[]>(),
});

That obviously doesn't yet give you belongsTo or hasMany or any of that, but it's a start!

[dwickern]

@dfreeman I ran into an interesting situation here: extending a generic class and applying a generic mixin. Here's the code I wanted to write:

class PromiseArray<T> extends Ember.ArrayProxy<T>
  .extend(Ember.PromiseProxyMixin<PromiseArray<T>>) {}

We had a workaround for generic mixins but here we also have a generic type on the left-hand side of .extend

[dfreeman]

As soon as the extends target changes from being a type to being an expression, any type parameters go out of scope because of that TS issue I linked in the Enumerable<T> PR :(

If this were an implementation instead of just a declaration, the best I could imagine this being would be something like:

interface PromiseArray<T> extends Ember.ArrayProxy<T>, Ember.PromiseProxyMixin<PromiseArray<T>> {}
class PromiseArray<T> extends (
  Ember.ArrayProxy.extend(Ember.PromiseProxyMixin) as typeof Ember.Object
) { ... }