also emit type arguments with --emitDecoratorMetadata

[hypno2000]

At the moment:

class Article {
   @Relation
   author: OneRelation<User>;
}

emits:

__metadata('design:type', OneRelation)

My suggestion is that that instead of just type it would also include the type args.

Maybe something like this:

__metadata('design:type', {type: OneRelation, args: [{type: User, args: []}])

With the latter i don't have to repeat myself in decorator that this is a one relation to user as i have already specified this in type.

Thanks,
Reio

[mhegazy]

How are using the type information later on? Generics do not really have a runtime representation. So other than Array, how would the type parameter be used?

Also what about generic classes, how should OneRelation be represented in class Article.

[hypno2000]

declare class OneRelation<T> {
   fetch(): T;
}

@Collection('users')
class User {
    email: string;
    username: string;
}

In this case the type parameter would be used by the model framework to hook up the correct model (User) to this relation. For example article.author.fetch() instanceof User would be true. Model framework would need to load the data from correct store and instantiate a correct class. Its a runtime functionality.

At the moment i would have to repeat myself to let the framework know the target model like so:

@Collection('articles')
class Article {
   title: string;
   content: string;

   @Relation(User)
   author: OneRelation<User>;

}

What i would like to do is avoid specifying the User twice and let the framework to be smart and infer it from the type argument:

@Collection('articles')
class Article {
   title: string;
   content: string;

   @Relation
   author: OneRelation<User>;

}

I don't see how the arguments passed to generics have any less runtime representation than any other types in typescript.

I realise that interfaces don't have runtime representation and they are just emitted like this:

__metadata('design:type', Object)

Which does not give much info tbh but thats a different subject.

I think emitting the type arguments would be useful as it makes possible the frameworks to infer more type info from the type itself rather than needing to duplicate it via decorator. I think thats the reason why the --emitDecoratorMetadata option was created.

[mhegazy]

EmitDecoratorMetadata emits values, and not serialized types. So it only works with classes and native types. This is because classes act as both a type at design time and a factory at run time (I.e. Constructor function). And native types have matching boxed types that can be used as constructors at runtime as well. Interfaces as you noted do not have this duality.

Generic types have no parallel at runtime, they are mearly a design time construct that allows for describing type relations. Similar to interfaces. The code sample above will assume something about the type OneRelationship, and in effect treats the generic type argument as an argument to the decorator.

I believe what you are asking for is a full type serialization thst is available at runtime. Got this I do not see why interfaces should be excluded. @rbuckton had a proposal for this; @rbuckton can you share your type serialization proposal here?

[rbuckton]

@mhegazy This gist contains some of my thoughts on a more comprehensive type serialization format.

[hypno2000]

Full type serialization would be awesome and would definitely solve my case.

[pavelsavara]

Full type information on runtime, specifically generic parameters, would probably allow to build smart factory methods. That assumes also decorated method calls. I guess lot could be learned from type erasure mistakes in Java.

[dsebastien]

+1 for full type information at runtime. There are many cool things that we'll be able to do with these.

[rbuckton]

@pavelsavara, @dsebastien: I've been considering this, but truly capturing full type information would require not only compiler support but a full runtime library. I have an updated gist with a tentative JSON schema for type information. There are still many issues to consider, such as the fact that TypeScript uses structural typing for interfaces and assignability, so its generally not enough to state "Inject an IMyService instance into this constructor parameter", if you have a class with the same shape that is not an IMyService instance.

In general, strings or symbols will likely always be a better choice for use cases like dependency injection as they are easier to work with, are more reliable, and don't have the runtime overhead of a runtime library for interpreting type relationships.

[pavelsavara]

As I said before, the IoC usecase could be satisfied with only type name emmited by compiler. Structural interface inference at runtime is not really necessary, rather nice to have. Do you plan to add support for interface name emmision for constructor parameters ? Or perhaps add extension points to the compiler service to enable it ?

[mhegazy]

I do not think we will emit type names, just because they do not make much sense in a structural type system. emitter extensibilty is something that is on our radar.

[meirgottlieb]

@rbuckton when considering a format for JSON type information and a library to work with it, take a look at these two projects:

Generates type information in JSON format:
https://www.npmjs.com/package/tsreflect-compiler

Library for working with type information in Node:
https://www.npmjs.com/package/tsreflect