Skip to content

TypeScript type metadata symbols and interfaces #3148

Closed

Description

I have some questions about the metadata symbols that are added by the TypeScript compiler to the generated JavaScript code when using the --emitDecoratorMetadata flag and decorators.

I'm aware of:

  • "design:type" [The serialized form of the type of ?] the decorator target
  • "design:paramtypes" [The serialized form of ?] the return type of the decorator target if it is a function type, undefined otherwise.
  • "design:returntype" A list of [serialized ?] types of the decorator target’s arguments if it is a function type, undefined otherwise.

Is the "design:name" symbol is available?

  • "design:name" The name of the decorator target

I'm hoping to find a symbol that will add the reflect-metadata that I need. I think I'm looking for something that is not available, something like design:implementedtypes or design:interfaces.

What I want to be able to do is be to get the names of the implemented interfaces.

@somedecorator
class Ninja implements INinja, IWarrior {
   // ...
}

The metadata that I would like to be added by the compiler is something would be something like the following:

Reflect.metadata("design:implementedtypes", ["INinja","IWarrior "]);

As an alternative (I don't know if that is the case) it would be OK for me if the "design:type" added the interfaces as well.

Reflect.metadata("design:type", ["Ninja", "INinja","IWarrior"]);

Also, are the serialized form of the types emitted?

reflect.metadata("design:type", ["Ninja"]);

or the actual types?

reflect.metadata("design:type", [Ninja]);

Thanks

Activity

  1. DanielRosenwasser commented on May 14, 2015

    @DanielRosenwasser
    Member

    Hey Remo H. Jansen (@remojansen), I'm not as familiar with decorators as some others on the team, but perhaps this comment may answer your question to some extent. If not, I can try to ping a few others from the team to help answer.

  2. remojansen commented on May 14, 2015

    @remojansen
    ContributorAuthor

    Daniel Rosenwasser (@DanielRosenwasser) thanks for the help.

    I had a few questions and now I have some answers:

    • Are strings used as the serialized forms of a type? No, and interfaces are serialized to Object.
    • Also, are the serialized form of the types emitted? Yes but serialization does not work as I expected. If somebody reach this page wondering the same please note that the types are not serialized into strings.

    But I still have some questions:

    • Is the "design:name" symbol is available? This will return a string I assume?

    And I would like to get more people to think about this issue because in the issue above (#2305) I see that giancarloa said:

    it all looks great EXCEPT the interfaces... don't you think it's a serious problem that there's no way to query metadata for interfaces? in my case for example I would never ever do the first example I gave above. Instead I would always do the second which is program against an interface.

    Maybe more developer feel this way and we need to consider some solution. Maybe the solution is a new metadata symbols like the one I was making up in my original question "design:interfaces". I understand that you cannot return the interface as an object so maybe we instead of "design:interfaces" need string versions of all the currently available symbols, something like "design:stringified_type" which would generate ["Ninja", "INinja","IWarrior"] for

    @somedecorator
    class Ninja implements INinja, IWarrior {
       // ...
    }
    

    Thanks

  3. DanielRosenwasser commented on May 14, 2015

    @DanielRosenwasser
    Member

    Is the "design:name" symbol is available? This will return a string I assume?

    The types of our decorators may help describe what you're interested in.

    • For a property, you'll get the name of the property.
    • For a method/accessor, you'll get the name of the method/accessor.
    • For a parameter in a method/accessor, you'll get the name of the method/accessor.

    Ron Buckton (@rbuckton) can feel free to correct me.

    Maybe more developer feel this way and we need to consider some solution.

    I think the following #3015 (comment) is relevant.

  4. rbuckton commented on May 14, 2015

    @rbuckton
    Contributor

    Remo H. Jansen (@remojansen) We are considering adding more type information. My current proposal can be found here.

  5. remojansen commented on May 14, 2015

    @remojansen
    ContributorAuthor

    Ron Buckton (@rbuckton) thanks for letting me know. I took a look to your proposal and I found what I need:

      /**
        * Implemented interfaces.
        */
      implements?: Type[];
    

    Do you have an open issue / proposal somewhere that I can follow to keep an eye on the updates regarding this topic? If there is an open issue / proposal already we can close this issue.

    Thanks

  6. DanielRosenwasser commented on May 15, 2015

    @DanielRosenwasser
    Member

    Hey Remo H. Jansen (@remojansen), I think the plan is to convert Ron Buckton (@rbuckton)'s proposal into a formal issue; not sure when we'll be doing that, so maybe we'll leave this open for now.

  7. mhegazy commented on Jun 12, 2015

    @mhegazy
    Contributor

    looks like this is already covered here: #3015 (comment)

  8. locked and limited conversation to collaborators on Jun 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    DuplicateAn existing issue was already createdSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions