microsoft
allow decorators for functions
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)
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.
@bal1anD Just check yourself:
The standardization effort of function decorators has been moved to https://github.com/iddan/proposal-function-expression-decorators .
The proposal is still stage 0. It builds upon the decorator porposal, which is still only stage 2. Don't expect this anytime soon.
Using decorators in functions! Why? We can use higher order functions that is even much better and handle more use cases that decorators can not handle.
@menocomp: well, in that case, why introduce decorators in TS at all? All of their use-cases can be solved by higher-order functions? The reason is elegance, clean-code.
Using decorators in functions! Why? We can use higher order functions that is even much better and handle more use cases that decorators can not handle.
I agree, we shouldn't care about "syntax sugars" which introduce layer over layer over layer just to reduce negligible amount of additional characters typed. And I certainely don't think introducing new constructs to the language actually makes code "elegant" and "clean". Usually it makes code shorter, but often tradeoff is that code becomes harder to reason and learnng curve is getting steeper and we all know too "smart" short code is no good. Imagine Junior programmer reading code top-down. I bet such person won't know how decorators work, when they are executed etc. They're not self-explanatory like higher-order functions which you understand quickly when you grasp that function can return function. Decorators feel a bit like "magic" and that's it for dozens of juniors.
But the core problem here is with additional value provided by decorators in TypeScript via experimentalDecorators and emitDecoratorMetadata flags for classes, which is very useful and good reason to use them. For example ability to obtain metadata about function parameter types provided by compiler to the runtime. I don't think such feature is currently possible without "Class" construct.
From my perspective this is what makes current state of TypeScript favor OOP over Functional Paradigm, especially when it comes to solving problem of dependency injection conviniently, which is an extremely important one.
Decorators for function would be extremely useful for react, so instead of this:
export const Component = memo(function Component() {
return <div>Component</div>
})
// or
function Component() {
return <div>Box</div>
}
const _Component = memo(Component)
export { _Component as Component }
We could have just
@memo
function Component() {
return <div>Component</div>
}
I think this could be done using a hack instead of waiting for js to support decorators or change things in hoisting we do something different basically all what is needed from typescript is supporting the syntax itself and this syntax could be transpilled to javascript syntax normally, how this could be done?
aft first anonymous functions could not be supported so let's stick with functions and suppose we have this function:
@logger
function fetchData() {
await fetch('resource')
}
logger actually will not be a class or method decorator to avoid dealing with descriptors, instead of that it will be a higher order function as the following:
function logger(target) {
return (...args) {
// do whatever you want
return target(...args)
}
}
when typescript compile the code it should output something like this:
function fetchData() {
logger()
// ...other decorators
return _fetchData();
}
I think this could be a start
I think this could be done using a hack instead of waiting for js to support decorators
Auch hacks are explicitly out of scope for TypeScript.