Decorator Metdata: expose array element type

[thomas-mindruptive]

TSC 175, target ES6, Node 5.6

Sample class with decorated properties:

@sg.DMClass
export class User implements IUser {
    @sg.DMProperty
    firstName: string;
    @sg.DMProperty
    lastName: string;
    @sg.DMProperty
    friends: User[];
}

Property decorator:

export function DMProperty(target: any, key: string) {
    var type = Reflect.getMetadata("design:type", target, key);
}

Current behaviour:
When the decorator gets called for property "friends", "type" is "Array" and the captured type ("User") is lost.

Expected behaviour
"type" should contain the captured type ("User"), too

Following very dirty work-around does the job: I modified tsc's method "emitSerializedTypeNode":

function emitSerializedTypeNode(node) {
    if (node) {
        console.log("*** emitSerializedTypeNode: node.kind: ", node.kind);
        switch (node.kind) {
            ...
            case 157:
                // Begin dirty ---------------------------------------------------------------------------
                var _elemType = node.elementType.typeName.text;
                write("{name: 'Array<" + _elemType + ">', type:'Array', elemType:'" + _elemType + "'}");
                console.log("*** emitSerializedTypeNode: Array, type: ", node.elementType.typeName.text);
                // End dirty -----------------------------------------------------------------------------
                return;
            case 150:
            ...

Best
Mind

[mhegazy]

looks like a duplicate of #4521

[thomas-mindruptive]

Hi Mohamed,
sorry to bother you again. I don't think it's a duplicate of 4521. 4521 deals with the order of loading the modules, respectively circular refernces. That's not a problem in my case. All the modules are loaded correctly but as I can see from the compiler code (emitSerializedTypeNode), the captured type of a generic array is not emitted. Only "Array" gets emitted. So this behaviour is not (yet) in the compiler's code.
Best
Mind

[mhegazy]

thanks. changing the title to reflect the request.

[thomas-mindruptive]

Thanks a lot!
Mind

[abierbaum]

Running into the same issue here. Would be very helpful if we could get to the full nested type information.

[DanielTWalther]

This problem apparently still persists. And it really is a dealbreaker for one of my current projects. In an attempt to implement a workaround of my own, much like and inspired by @mindruptive , I created a fork of the TS Compiler, which currently achieves JS outputs along the lines of e.g.:

__metadata('design:type', {name: 'Array<Array<Number>>', type: Array, elemType: {name: 'Array<Number>', type: Array, elemType: Number}})

or

__metadata('design:type', {name: 'Array<InnermostTestClass>', type: Array, elemType: TestClass_1.InnermostTestClass})

for (nested) Arrays as well as lessen the condensing of UnionTypes like so:

__metadata('design:type', Boolean | Number | String)

I realize that this workaround, which is sufficient for said project, creates a breaking change to the behavior of metadata, as (e.g.) the return parameter of Reflect.getMetadata('design:type', target, key?) is no longer guaranteed to be a constructor.
My question (and request) now is: can/will this be resolved?

[DanielTWalther]

It seems as though there is actually some progress regarding this issue. From what I can tell after looking at the current TSC, there seems to be a modified implementation of the metadata decorators (and two separate instances of said decorator emitters (function addOldTypeMetadata and function addNewTypeMetadata); the new one (when enabled) currently emits javascript code like this:

__metadata("design:typeinfo", {
  type: () => Array
})

I'd suggest modifying the output to emit:
(e.g.: number[][])

__metadata("design:typeinfo", {
  type: () => Array,
  elementType: () => {
    type: () => Array,
    elementType: () => Number
    }
})

This approach is obviously more elegant than building custom constructor functions (with or without a class or object mantle) to inject the elementType into.

[mhegazy]

I should note that Decorators have a new proposal in TC39 that should facilitate adding additional meta-data fields such as this one. I would expect TypeScript to implement the new proposal in the coming releases.