TypeScript interfaces for Dependency Injection

[pavelsavara]

I tried to imagine how could I use new Decorator Metadata in order to autowire dependency injection with TS interfaces. Test with tsc 1.5 beta gives me Object constructor instead of interface constructor (perhaps obviously), but that limits the ability of DI container to wire the dependency by type of the interface (as is usual in C#).

This would be the sample.

///<reference path="node_modules\reflect-metadata\reflect-metadata.d.ts"/>

import "reflect-metadata";

export interface IEngine{
}

export class Engine implements IEngine {
}

export class TestEngine implements IEngine {
}

function Inject() {
  return function (target: Function) {
  }
}

@Inject()
export class Car {
  constructor(public engine: IEngine) {}
}

tcs 1.5beta compiles to this

var Car = (function () {
    function Car(engine) {
        this.engine = engine;
    }
    Car = __decorate([
        Inject(), 
        __metadata('design:paramtypes', [Object])
    ], Car);
    return Car;
})();

Ideally the line should be

        __metadata('design:paramtypes', [IEngine])

and IEngine could be dummy class/constructor.

Or it could be string full name of the interface type

        __metadata('design:paramtypes', 'IEngine')

I tried to explain this to Angular team before here
angular/angular#135

[mhegazy]

and what is IEngine? given your sample IEngine === undefined...

[pavelsavara]

That's right, ts does't generate dummy classes for interfaces, (yet ?).
But it would be ideal to generate something visible on runtime.
It doesn't have to be class, it could be string with interface name.
So that DI framework could bind specific implementation of the interface to it, in it's configuration.

[mhegazy]

I would say what you want is #3015 instead :D. this way you get the type information at runtime.

[pavelsavara]

Not really, my point is about interfaces. If the class member in #3015 was defined as interface, what would get generated for runtime ?

[mhegazy]

The structure of the type. See @rbuckton's comment: #3015 (comment)

[pavelsavara]

I see, if full type information would be available on runtime as @rbuckton proposes, including interfaces, that would solve this need greatly. I really like that proposal.

But this specific scenario could be solved with less than that.

[sccolbert]

FWIW - I've built a simple DI library for typescript which (ab)uses the fact that there is a separation between the type namespace and the variable namespace.

It uses a runtime token which captures the interface type, but which is assigned (by convention) to the same name as the interface it is representing. This allows the dependencies to be declared, registered, and resolved at runtime using the token object, and it's all completely type-safe.

[pavelsavara]

@sccolbert nice pragmatic workaround.
In this request I hope to get compiler to provide the type 'handle/token' for the interface injection in consuming component. (instead of manual $inject)

[sccolbert]

@pavelsavara agreed, that would be ideal.

[brendanowen]

Currently I have to manually give my interfaces a name. By convention I exploit you can use the same name of the string variable as the interface name. TypeScript works out the difference depending on the context. For example someNameSpace.ISomeInterface is a string normally and is an interface if used with a : I still have to manually match the order to the $inject array with the parameter list in the constructor. I would love to be able to remove the need to manually give the interface a string name and line up the string names with the interface names. I am considering writing my own grunt task to preprocess my TypeScript files to annotate them with the convention I use below. I would like to say how this above issue plays out first.

// File: some/name/space/ISomeInterface.ts
module someNameSpace {

export var ISomeInterface:string = "someNameSpace.ISomeInterface";
export interface ISomeInterface {

    someProperty:number;
}

}

// File: some/name/space/SomeConcrete.ts
///
module someNameSpace {

export class SomeConcrete implements someNameSpace.ISomeInterface {

    public someProperty:number = 10;
}

}

// File: some/name/space/SomeObject.ts
///
module someNameSpace {

export class SomeObject {

    public static $inject:string[] = [someNameSpace.ISomeInterface];

    constructor(injectedObject:someNameSpace.ISomeInterface) {
    }
}

}

// File: some/name/space/application.ts
///
///

someModule = angular.module("someModule", []);
someModule.service(someNameSpace.ISomeInterface, someNameSpace.SomeConcrete);
someModule.service("someNameSpace.SomeObject", someNameSpace.SomeObject);

[rbuckton]

There are two problems with using TypeScript interfaces for any kind of dependency injection:

• TypeScript interfaces use structural typing. In other words, the following two interfaces are synonymous:

interface A { x: number; }
interface B { x: number; }

• Interface names are unreliable. In the face of import aliases in ES6, and our support for separate compilation for modules, it may not be feasible to accurately map an interface usage in one file back to its declaration in another module by name alone.
• Classes at run time do not carry information about their implemented interfaces.

As such, dependency injection scenarios using decorators will always need some other means for identifying dependencies. This either means using classes (as they have a unique runtime identity), strings, symbols, or some other unique key.

@pavelsavara, there are issues with emitting any kind of type handle for interfaces:

• These handles would violate structural typing
• There would need to be a way to uniquely define them in a reliable fashion not only from build to build but also through declaration files.
• There would need to be a consistent approach to applying them to classes.

The comment that @mhegazy mentioned points to a gist that describes a JSON-like language for describing types. This is more useful for scenarios like runtime type assertions than it is for dependency injection, and would necessitate an additional library just to be able to easily reason over things like union types, etc.

As it stands, the approaches that @sccolbert and @brendanowen outline above are a consistent and convention based compromise that looks viable. That said, we will continue to investigate suggestions and alternatives.

[pavelsavara]

@rbuckton thanks for your research. Few ideas

• if you emit metadata about each compile-time interface, you could let the DI library to figure out the structural equality on run-time.
• the DI could be specifically configured by the user that the A == B. Even better, if the metadata itself would implement equals() method.
• perhaps you could emit the metadata only from .ts files, but not from .d.ts
• perhaps interface itself could be annotated by desired global run-time handle or global-name ?
• could we 'export interface' to overcome module boundaries ?

@sccolbert Ideas in different direction

• what if constructor/method parameters could be annotated individually (like in C#), would it allow us to improve on manual $inject ?
• what if typescript compiler would allow some meta-programming/macros ?

[mhegazy]

looks like this is already covered in #3015 (comment)