6 ms·
Really looking forward to class decorators.
by JoshGlazebrook 9y ago
Really looking forward to class decorators.
- spleeder 9y agoI for one am not. What is wrong with calling a plain function?
- SimeVidas 9y agoYou need to use `.bind()` to set the context, or switch to using arrow functions. Both methods are sub-optimal. `@autobind` solves that.
- k__ 9y agoClass properties solve that too, with less magic IMO.
- dtzur 9y agoDecorators are awesome! Stop this blasphemy.
- tlrobinson 9y agoWhy is @autobind foo() { // ... } more optimal than foo = () => { // ... } ?
- jopsen 9y agoPlease, Nothing is ever _more optimal_.
- solidr53 9y agoBad example, checkout mobx or core-decorators. @computed get value() { return this.a + 1; } @readonly bar = 5;
- RonanTheGrey 9y agoThe use of decorators in Anguar 2/4 is also very well done, IMHO. They allow your class to focus on its business logic, rather than the minute details of how Angular expects it to interact with the rest of Angular. There's a reason all the most common languages have them, concealing complexity is a way to reduce cognitive overload and therefore, bugs.
- abritinthebay 9y agoDecorators are one of those things that I've not seen a use case that sells them to me. Like... I'm sure one day I'll see something and it'll just click, but not there yet.
- saghm 9y agoI'm the same way, except less sure that I'll find something that will change my mind.
- abritinthebay 9y agoMaybe “sure” was overly optimistic. “Hopeful” might be better put. I like the idea but I’ve yet to see a case that leads to better Code than other implementations.
- solidr53 9y agohttps://mobx.js.org/best/decorators.html https://mobx.js.org/best/decorators.html
- abritinthebay 9y agoThat... doesn't help. From what I see there I get harder to follow, non-idiomatic to anything in JS, code but the bonus is a terser syntax? 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)`.
- danielbarla 9y agoWell, in C#-land, we often use / abuse attributes to get information about a class or property at runtime. This way, framework or library code can inspect entities that you've authored, and dynamically deal with them. Perhaps a decent example is validation, where a declarative style has gained a lot of popularity. A JS example might be: @required firstName; This simply declares the intent / rule, but does not provide the implementation. 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.
- andreineculau 9y agoOh please. Decorators will never beat plain old functions when it comes to flexibility.
- rhencke 9y agoC will never beat plain old assembly when it comes to flexibility.
- hajile 9y agoHardly a fair comparison. Decorators exist in Python and other languages primarily because they either don't have lambdas or have bad ones. JS doesn't suffer from those problems, so the mental overhead of the additional syntax has a much lower payoff (and one that I believe isn't worth the trouble).
- deleted 9y ago[deleted]
- tlrobinson 9y agoReally wish they had included function decorators too. https://github.com/wycats/javascript-decorators/issues/4 https://github.com/wycats/javascript-decorators/issues/4
- netcraft 9y agoI wish we could get macros then we could make our own decorators... (macro support in typescript would be awesome)