Improvement: Design metadata should contain property names and types

[Cedware]

At the moment it's not possible to get all Properties of a Type with the corresponding design-type of the property.
It's only possible to get all properties of an object by using Object.keys() and this wouldn't return properties which haven't been set, of course the simply don't exist.
So it wold be a great feature, if a class which emits metadata because of a decorator would also emit a metadata called something like 'design:properties' which contains a list of all property-names with the corresponding type.

[mhegazy]

Can you elaborate on the scenario you are trying to achieve?

[Cedware]

Alright lets take a look at this simple class:

export class MyClass{
    public stringProperty: string;
    public numProperty: number;
    constructor(stringParam: string){
    }
}

with --emitDecoratorMetadata the following code is emitted:

var MyClass = (function () {
    function MyClass(stringParam) {
    }
    MyClass = __decorate([
        my_decorator_1.myDecorator, 
        __metadata('design:paramtypes', [String])
    ], MyClass);
    return MyClass;
}());

I think it would be useful, if the emitted js would contain additional metadata which describes the designtime properties of the class:

var MyClass = (function () {
    function MyClass(stringParam) {
    }
    MyClass = __decorate([
        my_decorator_1.myDecorator, 
        __metadata('design:paramtypes', [String])
        __metadata('design:properties', [
        {name: 'stringProperty', type: String, visibility: 'public'},
        {name: 'numProperty', type: Number, visibility: 'public'}
        ])
    ], MyClass);
    return MyClass;
}());

So Reflect.getMetadata can be used to get all properties of a type in the same way it can be used to get all parameters of the constructor:

let constructorParams = Reflect.getMetadata('design:paramtypes', MyClass);
let propeties = Reflect.getMetadata('design:properties', MyClass);

I hope this makes the scenario more understandable

[leviathanbadger]

For what it's worth, I agree with this feature request entirely. The exact format of the properties and the name of the metadata decorator are up for interpretation, but the feature itself needs to be here in some form.

A question that comes to mind (not a problem): should we store "readonly" and other type modifiers in this way?

[aluanhaddad]

With the recent decision to emit assignments of undefined for class property declarations without an initializer this might make more sense than it once did. This might have to be under an additional flag as the size of the emit would increase dramatically.

@aboveyou00 I don't think serializing private, public, or readonly would make sense at this point. Certainly not until the private fields proposal works its way further through TC39.

[listepo-alterpost]

Hi, any news?

[IonelLupu]

There has been almost one year. Are there any updates on this? @Cedware @mhegazy

[ghost]

Hey guys, any updates on this? thx

[IRCraziestTaxi]

This is exactly what I need! What's the status on this?

Also, @aluanhaddad, what do you mean by "the recent decision to emit assignments of undefined for class property declarations without an initializer"? That sounds very promising for what I'm trying to do, but I'm not sure what you're referencing and google with those and similar search terms doesn't turn up anything for me.

[nodkz]

Is there a way to make USE_NEW_TYPE_METADATA_FORMAT=true for
https://github.com/Microsoft/TypeScript/blob/90b304aa5e93a8195e4b8bcfb65b0079391cb9cf/src/compiler/transformers/ts.ts#L1659-L1661

It will unlock desired behavior
https://github.com/Microsoft/TypeScript/blob/90b304aa5e93a8195e4b8bcfb65b0079391cb9cf/src/compiler/transformers/ts.ts#L1681-L1697

[nodkz]

This feature was reverted in #7878 by @rbuckton

@mhegazy said on Apr 7, 2016

As discussed offline, we should limit the breaking change for this iteration, and include these changes later on.

But what about just adding design:typeinfo to the old method addOldTypeMetadata without breaking changes?
https://github.com/Microsoft/TypeScript/blob/90b304aa5e93a8195e4b8bcfb65b0079391cb9cf/src/compiler/transformers/ts.ts#L1693-L1695

[IonelLupu]

@nodkz is this really possible? I am hunting these new features of TS that are about to be introduced. for one of my projects.

These features will make Typescript become a next level language. I think we need to add a flag or something to ts that opens a new set of features like this.

[nodkz]

@IonelLupu it possible if you write own custom transpiler via Compiler API and use ttypescript.

[cyraid]

Doesn't every other programming language that support annotations at least allow you to list them from a class?

In my opinion, there really has to be an easier way to include decorators and annotations..

The biggest use case (that I've noticed), is that people just want to annotate and find out fields and classes that have annotations on the fields, parameters, classes, methods at runtime.

There should be a standard way that one can just create a class that can be used for annotations like in Java. Some standard boilerplate that can be included from say, reflect-metadata.

Then have standard functions that allow you to get from a class or method and a 'get all annotations from' as well.

[guillotjulien]

This is still work in progress but I've developed a little decorator that allow the user to retrieve such information from the decorated class properties: https://github.com/guillotjulien/object-seeder

I'm also working on a V2 that should address some of the flaws of the current implementation, but I've been using V1 since ~1 year (prior to NPM package) on multiple enterprise projects without any significant issues.

For example, we used those metadata to create a SQL like DSL that can validate selected properties against model available properties.

[sekko27]

We also need this feature for our project (making DI bean resolutions depends on param names too).

I've made modification in tsc.ts to emit design:paramnames metadata too. I can not create PR because there is no associated issue with Backlog milestone (tests are updated, PR merge-able).

• I did put the param names resolution into the same serialization function as the param types, so param names will be emitted when param types will.
• I renamed this serialization function.

You can check the diff at master...sekko27:master

Could you assign the Backlog milestone for this issue?

[sekko27]

is this issue alive?

[mdnmdn]

I hope so

[DHager]

In particular, I would really like to be able to get the value of a read-only instance property, which should theoretically be available from a static context.

I may need to do something weird where there's a static property and the read-only instance property is always set to the static value...

[rezonant]

I am definitely interested in reflecting upon visibility, the list of class properties themselves, and even more importantly: instructing Typescript to emit metadata for all compiled code. I'm certainly willing to incur longer startup times and higher memory usage to enable this. I don't believe that emitting RTTI for all types will cause ongoing runtime perf but would love to hear otherwise if it's believed to be the case.

I hope feature development around RTTI is still being considered!

[mattvb91]

Currently looking for this functionality too including the possiblity to check wether or not a decorated attribute is optional or not so it could look like this?

        {name: 'numProperty', type: Number, visibility: 'public', optional: true}

[IonelLupu]

@mattvb91 Looking for this feature as well.

What typescript compilers are you all using to get this information until we wait for Typescript to support this by default?

[mattvb91]

@IonelLupu currently trying to use the compiler API to parse it out manually but it could definitey be made a lot simpler by including this feature here

https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API

[rezonant]

There have been many attempts at doing this in a transformer, but they all have had deficiencies. I'm throwing my hat in the ring with a new attempt:

https://github.com/rezonant/typescript-rtti

Would love to hear any feedback (on that project, so as to keep noise down for the subscribers here), and especially for people to try it out against their codebases as there may be corner cases that don't work just yet.