Really looking forward to class decorators.
Like... I'm sure one day I'll see something and it'll just click, but not there yet.
Like, I get they can be used for stuff but why are they a better option?
So far - based on the responses here - it appears to be syntax for syntax sake and no practical benefit.
Terse at the usage point yes, but it swaps clarity for brevity. A sometimes useful trade off to be sure but... not sure I’ve seen any demonstration of benefits here.
@required firstName;
We can argue terseness vs verbosity, implicitness vs explicitness all day - I'd argue that for certain basic things that you do highly frequently, a terse and implicit style is not a bad thing. It tends to increase the signal-to-noise ratio of your code, allowing the developer to focus on things that really are interesting, and not have to read through a lot of boilerplate.
If we were talking about very basic things then yes, sure, but I’d also argue that if they are truly basic then we could restrict decorators to built-in ones only (as those are the basics).
Much like there are “magic” Symbols like Symbol.iterator.
I like the idea but I’ve yet to see a case that leads to better Code than other implementations.
Other use cases that I see are for example automatically generating [de]serialization code for members based on decorators and their values (like how Annotations are used in C# and Java serialization frameworks or tags in Go).
There are also web frameworks popping up which use decorators for routing and parameter binding in a similar fashion how some Java frameworks work.
Great...?
I really hope there's a better use case for them because this is not selling me. Literally none of that post is a compelling case.
I get the cleaner syntax, that's nice, but it also means now I have to look up what that does. And that decorated properties example? Yikes that's awful - it looks like a code-smell frankly.
But all that initial urrrgh factor could be removed by showing me a use case that makes the code significantly more elegant to do `@foo bar` rather than `foo(bar)`.
@autobind
foo() {
// ...
}
foo = () => {
// ...
}
?@computed get value() { return this.a + 1; } @readonly bar = 5;
There's a reason all the most common languages have them, concealing complexity is a way to reduce cognitive overload and therefore, bugs.