Skip to content

"design:paramnames" metadata key #4905

Open
Open
"design:paramnames" metadata key#4905
Labels
Domain: DecoratorsThe issue relates to the decorator syntaxIn DiscussionNot yet reached consensusSuggestionAn idea for TypeScript

Description

@remojansen
Remo H. Jansen (remojansen)
opened on Sep 21, 2015

From #2589

A few notes on metadata:

  • Type metadata uses the metadata key "design:type".
  • Parameter type metadata uses the metadata key "design:paramtypes".
  • Return type metadata uses the metadata key "design:returntype".

Can you please add support for a "design:paramnames" metadata key? It would return the design-time names of the arguments of a function

I can convert a function to string at runtime using Function.prototype.toString() and then use a couple of Regex to get the parameter names:

STRIP_COMMENTS = /((\/\/.*$)|(\/\*[\s\S]*?\*\/))/mg;
ARGUMENT_NAMES = /([^\s,]+)/g;

But when a minifier/compressor is used the param names become "a", "b" ...

I would like to have a way to access the design-time names of the arguments of a function at run-time even after compression.

Activity

  1. Dan Quirk (danquirk)
    added
    SuggestionAn idea for TypeScript
    Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.
    on Sep 21, 2015

  2. RichiCoder1 commented on Sep 22, 2015

    @RichiCoder1
    Richard Simpson (RichiCoder1)
    on Sep 22, 2015

    If I may ask, what's the use case of this?

  3. remojansen commented on Sep 22, 2015

    @remojansen
    Remo H. Jansen (remojansen)
    on Sep 22, 2015
    ContributorAuthor

    Richard Simpson (@RichiCoder1) Sure, I'm working on a inversion of control container and I want to add contextual binding support. One of the things that I want to allow developers to do is to use constraints based on the injection target. Take for example:

    class Soldier {

  private _mainWeapon : IWeapon;
  private _secondaryWeapon : IWeapon;

  constructor(main : IWeapon, secondary : IWeapon) { // injections
    this._mainWeapon = main;
    this._secondaryWeapon = secondary;
  }
}

    When I declare the bindings I can use a constraint to resolve ambiguous bindings:

    kernel.bind(new Binding<IWeapon>(Katana).when((target) => { return target.name === "main" }));
kernel.bind(new Binding<IWeapon>(Shuriken).when((target) => { return target.name === "secondary" }));

    My problem is that If the javascript is compressed, the value of target.name would be "a" and "b" and the IoC container would not be able to resolve the service.

  4. RichiCoder1 commented on Sep 23, 2015

    @RichiCoder1
    Richard Simpson (RichiCoder1)
    on Sep 23, 2015

    Ahh, that would make sense.

  5. Mohamed Hegazy (mhegazy)
    added
    In DiscussionNot yet reached consensus
    and removed
    Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.
    on Sep 28, 2015

  6. Joshua-F commented on Jan 1, 2016

    @Joshua-F
    Joshua Filby (Joshua-F)
    on Jan 1, 2016

    I would love to see this added.

  7. remojansen commented on Jan 27, 2016

    @remojansen
    Remo H. Jansen (remojansen)
    on Jan 27, 2016
    ContributorAuthor

    Hi Mohamed Hegazy (@mhegazy) It's been a while since this was tagged as In Discussion. Do you have an update on this? Thanks!

  8. mhegazy commented on Jan 28, 2016

    @mhegazy
    Mohamed Hegazy (mhegazy)
    on Jan 28, 2016
    Contributor

    We do not intend to make any changes to decoratos implementation until the TC39 discussions about the current proposal are finalized. there will be some changes that we need to make with the latest draft of the proposal; after that is done, we can look into adding these additional feature requests.

  9. isuda commented on Jan 9, 2017

    @isuda
    Ian Suda (isuda)
    on Jan 9, 2017

    Mohamed Hegazy (@mhegazy) - Its been a year since your last comment on this. Any updates on when this might be able to be implemented? It would be super useful to be able to use this to do DI when code has been minified.

  10. Mohamed Hegazy (mhegazy)
    added
    Domain: DecoratorsThe issue relates to the decorator syntax
    on Nov 23, 2017

  11. sdc395 commented on Dec 8, 2017

    @sdc395
    Simon (sdc395)
    on Dec 8, 2017

    I'd also love to see this implemented as it would allow me to map the properties of an object (input parameters from a GraphQL query) on to the parameters of a function (the resolver). I was hoping to find a way to augment the metadata emitted by tsc but it seems compiler plug-ins are not yet a thing.

  12. sdc395 commented on Dec 8, 2017

    @sdc395
    Simon (sdc395)
    on Dec 8, 2017

    While we're at it, knowing the type a promise will return would also be very useful so metadata for generics too, please.

  13. raymondfeng commented on Dec 19, 2017

    @raymondfeng
    Raymond Feng (raymondfeng)
    on Dec 19, 2017

    +1. At LoopBack, we introduce decorators to annotate method parameters to describe how to map methods to REST APIs. It will be great that we can infer parameter types/names from the design time metadata. For example:

    @returnValue()
async createOrder(@param() order: Order): Promise<Order> {
  // ...
}

We would like to know:
- The parameter name ('order') N/A today
- The parameter type (Order) (It's already supported, but not for array item types)
- The return type (Promise) but we care more about `Promise<Order>`

  14. nodkz commented on Apr 9, 2019

    @nodkz
    Paul Damnhorn (nodkz)
    on Apr 9, 2019

    Duplicate #12626

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

    Domain: DecoratorsThe issue relates to the decorator syntaxIn DiscussionNot yet reached consensusSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions