Add support for generic types to the compiler

[Tragetaschen]

I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[x ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior
The compiler doesn't emit any generic type parameters and compiling that TypeScript code fails with Generic type ... requires 1 type argument(s)

Expected/desired behavior
The compiler should use generic type information

• Angular version: 2.0.0-rc.5
• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
• Language: [ TypeScript X.X ]

In my code base, there are a couple of places where I use generic types to help me share code while not lose type information. Up until now, these only existed at compile time and the runtime compiler only saw the JavaScript code without any type information. With the AoT compiler, I currently have to remove all that type information and reduce it to any (shudder), because the compiler just ignores generic parameters. There are two distinct examples in my code base, which I'll put into separate comments.

[Tragetaschen]

There is a generic service that provides user settings and within one application (read: bootstrap AppModule), these user settings have exactly one type, but from one application to the next, this type is different. SettingsService<T> is that generic class and my components declare SettingsService<AppSettings> for their constructor argument. Since the generated AppModuleInjector.getInternal only returns any, it seems like it could be sufficient to replace the generic type with any.

  get _SettingsService_98():import76.SettingsService {
    if ((this.__SettingsService_98 == null)) { (this.__SettingsService_98 = new import76.SettingsService(this._Http_82)); }
    return this.__SettingsService_98;
  }

becomes

  get _SettingsService_98():import76.SettingsService<any> {
    if ((this.__SettingsService_98 == null)) { (this.__SettingsService_98 = new import76.SettingsService<any>(this._Http_82)); }
    return this.__SettingsService_98;
  }

This also works with generic constraints. If you decide to be more strict about types in the generated code (like not "routing" the calls through interfaces that return any), this might become more difficult. However, I'm able to specify for the service the generic type parameter at the AppModule level.

[Tragetaschen]

My second use case is a bit more tricky, mostly because deducing the type parameter's type is a real challange.

I have a combination of a component and directive that make up a drop-down control. One is the root element that holds the current value DropDownSelectComponent<T>, the other is instantiated for each choice DropDownSelectOptionDirective<T>. Reduced, it looks like this:

class DropDownSelectOptionDirective<T> {
  @Input() public value: T;
}

class DropDownSelectComponent<T> {
  @Input() public value: T;
  @Output() public valueChange = new EventEmitter<T>();
  @ContentChildren(DropDownSelectOptionDirective) public options: QueryList<DropDownSelectOptionDirective<T>>;
}

<drop-down-select [(value)]="settings.SendEmail">
  <drop-down-select-option [value]="true">Yes</drop-down-select-option>
  <drop-down-select-option [value]="false">No</drop-down-select-option>
</drop-down-select>

This setup nicely declares the intent of how the component/directive are meant to work together. With runtime compilation, the generic types would be gone and the compiler would easily generate correct code. The AoT compiler currently doesn't emit any generic type parameters and produces code that doesn't compile.

If I could wish for something, I would like to declare that both value members' types define what T should be for that instance. The generated code would then check that the component's T matches that of the ContentChildren. A quick error to make in the example would be

<drop-down-select [(value)]="settings.SendEmail">
  <drop-down-select-option value="true">Yes</drop-down-select-option>
  <drop-down-select-option value="false">No</drop-down-select-option>
</drop-down-select>

and suddenly the type of the options is string, which is not compatible with the boolean deduced from SendEmail.

[hydralix]

Reproduced with angular:2.0.0-rc.7
Please fix it

[chuckjaz]

It is by design that we don't support type parameters in components and services.

There are some technical challenges that must be overcome and some TypeScript features that need to be added for this to be implemented correctly that we currently don't believe adding this support provides enough value to justify the cost of its implementation.

[Tragetaschen]

Is there already a list of patterns that the AOT compiler won't support, but work with the JIT compiler?
Is there a way to get an error for unsupported patterns before trying the AOT compiler for the first time?

[chuckjaz]

@Tragetaschen I am working on a document that explains what is supported and what is not but it is taking longer than I expected (my 2 week vacation didn't help much with this).

Right now the only way to get errors that will be reported by the AoT compiler is to run it.