did a quick search, it looks like this hasn't been yet requested
currently decorators can only be added to classes, methods and properties
consider allowing them on functions too
@aleksey-bykov it was discussed in here https://github.com/Microsoft/TypeScript/issues/2249#issuecomment-77690164
Please note that decorator proposal is undergoing churn now, and we would not be adding new features until we have a stable proposal.
@mhegazy just fyi that function expression decorators are at stage 0: https://github.com/tc39/proposals/blob/master/stage-0-proposals.md
And while the underlying implementation is undergoing some churn, the syntax has been stable for quite a while. It would be great to have this implemented behind a flag because angular users could then write tests with a much nicer syntax.
it('should do foo', @Injectable()(fooService:FooService) => {
...
});
compared to the current:
it('should do foo', inject([FooService], (fooService:FooService) => {
...
});
Any progress ? This will be really powerful feature. There is a lot of use cases.
I see on roadmap just support for function expression/arrow functions :(
I know the problem is with function hoisting.
But I think we can loos hoisting for decorated functions (especially if we are using modules).
Compiler is able to detect decorated function hoisting (and cycles) and just throw error.
I beg, do not give up :)
Related discussion:
wycats/javascript-decorators/Allow decorators for functions as well
This could potentially solve #10644 - it's a nasty side-effect when trying to use using bound methods feature with decorators :-(
My understanding of this issue is:
Decorators were added due mitigate the lack of expressiveness that was inherent in the _maximally minimal_ approach to classes that TC39 took.
My crude paraphrasing of the above is:
_ES2015_ classes are basically useless without decorators. They are a travesty of a class implementation.
Do they offer conciseness? No.
Do they enable expressing anything that is not better expressed with factories? Not for me.
Do they offer compositional approaches aside from unmaintainable 5+ class deep hierarchies? No.
Do the enable composition over inheritance? No. (ignoring all the lessons learned in C++, C#, Java)
Do they encourage depending on implementation? Yes!
Do they provide encapsulation? No.
The _Maximally Minimal_ appraoch fell flat on its face. The only reason to use classes is to use decorators, the feature has been proposed to make up for how worthless they are.
Wow, that was a fast 3 馃憥.
UPDATE: 2 馃憥 (thanks @majo44 for reconsidering 馃槅)
I am not saying decorators should not be allowed on functions.
I am saying that the reason they are not is because they were only added to make up for classes being useless.
Again Maximally Minimal approach to decorators is what leads that feature to be insufficiently generalizable to other constructs.
I would like to have function decorators.
I also want them on object literals because of the clean declarative syntax they offer.
Is this even possible? I saw a discussion on Babel about this and they ended up with impossibility to implement decorators on function because of their hoisting.
Is hoisting acceptable in TypeScript? (I don't know because I've never used that)
I beg, do not give up +1
The standardization effort of function decorators has been moved to https://github.com/iddan/proposal-function-expression-decorators . The decorator of function declarations and the hoisting problem is discussed in No. 3 issue.
Is there any news on this? Looks like nothing really changed in the last year or so.
AFAIU this is still blocked by the lack of JavaScripts ability to do that.
Hi there!
I just created a simple plugin that enables function decorators.
It is a system of two plugins: tsserver
plugin that removes errors and ts-patch
(ttypescript
) plugin that transforms decorated function to the corresponding expression.
Example
For some reason, this plugin can only be used with ts-patch
, not with ttypescript
.
And of course there are some limitations.
If the argument is that this will break hoisting, GOOD THEN. I hate hoisting anyways 馃槅
Jokes aside, the fact that decorators can only be used on classes is totally arbitrary. Everything is possible. Even a dangling decorator are technically possible to implement. This thread is more like convincing the right people to actually make it happen.
Most helpful comment
@mhegazy just fyi that function expression decorators are at stage 0: https://github.com/tc39/proposals/blob/master/stage-0-proposals.md
And while the underlying implementation is undergoing some churn, the syntax has been stable for quite a while. It would be great to have this implemented behind a flag because angular users could then write tests with a much nicer syntax.
compared to the current: