You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TypeScript type metadata symbols and interfaces #3148
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:
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.
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 {
// ...
}
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.
Activity
DanielRosenwasser commentedon May 14, 2015
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.
remojansen commentedon May 14, 2015
Daniel Rosenwasser (@DanielRosenwasser) thanks for the help.
I had a few questions and now I have some answers:
Object.But I still have some questions:
"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:
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"]forThanks
DanielRosenwasser commentedon May 14, 2015
The types of our decorators may help describe what you're interested in.
Ron Buckton (@rbuckton) can feel free to correct me.
I think the following #3015 (comment) is relevant.
rbuckton commentedon May 14, 2015
Remo H. Jansen (@remojansen) We are considering adding more type information. My current proposal can be found here.
remojansen commentedon May 14, 2015
Ron Buckton (@rbuckton) thanks for letting me know. I took a look to your proposal and I found what I need:
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
DanielRosenwasser commentedon May 15, 2015
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.
mhegazy commentedon Jun 12, 2015
looks like this is already covered here: #3015 (comment)