4 ms·

Deep introduction to class decorators in TypeScript

28 points by kiyanwang 5y ago

jitl 5y ago
Note that the decorators standard has changed substantially, and the experimental decorators implementation in Typescript now varies greatly from the existing proposals. The current feature has not been updated in years. I would not use this feature in my code, especially for critical facilities, or build a framework around it. For what it’s worth, it seems like the proposal may move towards stage 3 soon - another round of review is going on here: https://github.com/tc39/proposal-decorators/issues/442 https://github.com/tc39/proposal-decorators/issues/442 So, beware libraries or frameworks that rely on this toolset.
- xtracto 5y ago
  Just today i was bitten by a bug in a framework called NestJS that makes heavy use of decorators: Certain decorator they define doesnt work with Jest test framework.
  - dhritzkiv 5y ago
    I use NestJS with Jest just fine. Lots of decorators, too. What bug did you encounter?
  - davidmurdoch 5y ago
    Sounds like you were bitten by Jest inadequacies, no?
    - frenchy 5y ago
      Jest is inadequate because it doesn't support some non-standard experimental feature that was shoehorned into TypesScript to make it look more like C#?
      - davidmurdoch 5y ago
        This is a JavaScript feature and confusing the two makes finding answers to Typescript questions much harder. But yes, I think jest, a "JavaScript testing framework designed to ensure correctness of any JavaScript codebase" should support JavaScript features, even the ones you don't like the provenance of.
        magicalist 5y ago
        But decorators aren't a JavaScript feature, that's the point of this comment thread. Some form of them might eventually be a JavaScript feature, but anything using them now is potentially incompatible with that future form.
        davidmurdoch 5y ago
        Oh yeah, sorry, I shouldn't have worded it that way. the decorators are being transpiled at runtime to standard JS, so why shouldn't tooling like jest be able to work with that?
        xtracto 5y ago
        Because there is something wrong happening while the transpilation of the non-standard feature is happening.
- FinalBriefing 5y ago
  Yea, it makes me really worried about Angular's future updates given its heavy usage of decorators.
- hmillison 5y ago
  It’s truly insane to me that we’re still waiting on decorators from TC39. I’ve been seeing warnings to not use them SINCE shortly after ES2015. Since you’ve been able to use them for 7 years via transpilers, I wouldn’t hold my breathe on TC39 finally ending their bike shedding anytime soon. Feels like if the feature is useful to you, you should use it. If something changes, it would be an easy thing to codemod.
root_axis 5y ago
I do not like decorators. There, I said it. I'm all about a rational tech discussion, but I'm gonna put on my hater hat and say I think the syntax is stinky and I cringe when I look at a codebase littered with a smattering of side-effect labels. I know this is a superficial criticism so I will concede to those that have seen elegant use of decorators in action, I learn something new every day so perhaps I'll see the light eventually.
- syntheticcdo 5y ago
  In a current project, to support the "mix-in" style of development that decorators provide, I am preferring to extend the base class at class definition time, ie: class Example extends mixin(BaseClass) {} as opposed to the decorator style: @mixin class Example extends BaseClass {} If you dislike decorators, what are your thoughts on this style of code?
- BulgarianIdiot 5y ago
  Decorators don't work like annotations. They're functions applied to the function (or class) under them. As such, I find them much more direct and logical (and debuggable). Can you use them poorly? Sure, but this applies to anything. I.e. how is a decorator like this: @dec class Foo {...} Different than this? let Foo = dec( class Foo {...} ); It seems the same to me (mostly). The above has a better syntax.
  - chii 5y ago
    decorators are better because of scoping imho.
  - tobr 5y ago
    > They're functions applied to the function (or class) under them. Now that’s wrong. Decorators don’t work on functions, just methods. Which is ironic if you think about it, because if you program with functions you already have the tools you need to compose things, no need to invent some syntax sugar like this. For some reason object oriented programmers don’t seem to think like that. They want a special name and special syntax for everything.
cutler 5y ago
Springscript might be a better name for this monstrosity. Those who appreciate Javascript's functional roots will be throwing-up. As if classes and "constructor" were not enough.
- izelnakri 5y ago
  Identity politics based, brain-washed mentality in action. I do functional programming for years now and write JS more than a decade, and don't consider this feature to be a monstrosity. If anything, it is a nice addition to the language especially when it comes to designing ORMs. The fact that this became the most upvoted comment on hacker news signals me something sad about this sites moderation. In addition to the fact that other most upvoted comments(arguments) are lacking depth and good context: 1 - not standard so I won't use it(yet mitigating would be easy & basic and there is a major/popular implementation in typescript), 2- I don't like how it looks(decades long I'm an artist argument) Good arguments & discussions usually require in-depth knowledge, given how fast programming communities grow, there will be people who make these shallow arguments and they will get upvoted(will have more people agreeing to them). Sadly this means old communities like hacker news content and moderation will get spoiled by this behavior and standard committees will keep getting many noisy pushback & shallow criticisms as more people become programmers and will have tendency to share their newly formed opinions rather too quickly. I like and ok with criticisms, however I hope and expect them to be in-depth, not disappointingly this shallow.
samrocksc 5y ago
The cognitive overhead from decorators in TypeScript is the thing I have the biggest problem with. It's just one more differential between onboarding code fast, and having to slog through miles of code to figure out what a decorator is doing.

28 points by kiyanwang 5y ago

jitl 5y ago

Note that the decorators standard has changed substantially, and the experimental decorators implementation in Typescript now varies greatly from the existing proposals. The current feature has not been updated in years. I would not use this feature in my code, especially for critical facilities, or build a framework around it. For what it’s worth, it seems like the proposal may move towards stage 3 soon - another round of review is going on here: https://github.com/tc39/proposal-decorators/issues/442 https://github.com/tc39/proposal-decorators/issues/442 So, beware libraries or frameworks that rely on this toolset.

xtracto 5y ago
Just today i was bitten by a bug in a framework called NestJS that makes heavy use of decorators: Certain decorator they define doesnt work with Jest test framework.
- dhritzkiv 5y ago
  I use NestJS with Jest just fine. Lots of decorators, too. What bug did you encounter?
- davidmurdoch 5y ago
  Sounds like you were bitten by Jest inadequacies, no?
  - frenchy 5y ago
    Jest is inadequate because it doesn't support some non-standard experimental feature that was shoehorned into TypesScript to make it look more like C#?
    - davidmurdoch 5y ago
      This is a JavaScript feature and confusing the two makes finding answers to Typescript questions much harder. But yes, I think jest, a "JavaScript testing framework designed to ensure correctness of any JavaScript codebase" should support JavaScript features, even the ones you don't like the provenance of.
      - magicalist 5y ago
        But decorators aren't a JavaScript feature, that's the point of this comment thread. Some form of them might eventually be a JavaScript feature, but anything using them now is potentially incompatible with that future form.
        davidmurdoch 5y ago
        Oh yeah, sorry, I shouldn't have worded it that way. the decorators are being transpiled at runtime to standard JS, so why shouldn't tooling like jest be able to work with that?
        xtracto 5y ago
        Because there is something wrong happening while the transpilation of the non-standard feature is happening.
FinalBriefing 5y ago
Yea, it makes me really worried about Angular's future updates given its heavy usage of decorators.
hmillison 5y ago
It’s truly insane to me that we’re still waiting on decorators from TC39. I’ve been seeing warnings to not use them SINCE shortly after ES2015. Since you’ve been able to use them for 7 years via transpilers, I wouldn’t hold my breathe on TC39 finally ending their bike shedding anytime soon. Feels like if the feature is useful to you, you should use it. If something changes, it would be an easy thing to codemod.

root_axis 5y ago

I do not like decorators. There, I said it. I'm all about a rational tech discussion, but I'm gonna put on my hater hat and say I think the syntax is stinky and I cringe when I look at a codebase littered with a smattering of side-effect labels. I know this is a superficial criticism so I will concede to those that have seen elegant use of decorators in action, I learn something new every day so perhaps I'll see the light eventually.

syntheticcdo 5y ago
In a current project, to support the "mix-in" style of development that decorators provide, I am preferring to extend the base class at class definition time, ie: class Example extends mixin(BaseClass) {} as opposed to the decorator style: @mixin class Example extends BaseClass {} If you dislike decorators, what are your thoughts on this style of code?
BulgarianIdiot 5y ago
Decorators don't work like annotations. They're functions applied to the function (or class) under them. As such, I find them much more direct and logical (and debuggable). Can you use them poorly? Sure, but this applies to anything. I.e. how is a decorator like this: @dec class Foo {...} Different than this? let Foo = dec( class Foo {...} ); It seems the same to me (mostly). The above has a better syntax.
- chii 5y ago
  decorators are better because of scoping imho.
- tobr 5y ago
  > They're functions applied to the function (or class) under them. Now that’s wrong. Decorators don’t work on functions, just methods. Which is ironic if you think about it, because if you program with functions you already have the tools you need to compose things, no need to invent some syntax sugar like this. For some reason object oriented programmers don’t seem to think like that. They want a special name and special syntax for everything.

cutler 5y ago

Springscript might be a better name for this monstrosity. Those who appreciate Javascript's functional roots will be throwing-up. As if classes and "constructor" were not enough.

izelnakri 5y ago
Identity politics based, brain-washed mentality in action. I do functional programming for years now and write JS more than a decade, and don't consider this feature to be a monstrosity. If anything, it is a nice addition to the language especially when it comes to designing ORMs. The fact that this became the most upvoted comment on hacker news signals me something sad about this sites moderation. In addition to the fact that other most upvoted comments(arguments) are lacking depth and good context: 1 - not standard so I won't use it(yet mitigating would be easy & basic and there is a major/popular implementation in typescript), 2- I don't like how it looks(decades long I'm an artist argument) Good arguments & discussions usually require in-depth knowledge, given how fast programming communities grow, there will be people who make these shallow arguments and they will get upvoted(will have more people agreeing to them). Sadly this means old communities like hacker news content and moderation will get spoiled by this behavior and standard committees will keep getting many noisy pushback & shallow criticisms as more people become programmers and will have tendency to share their newly formed opinions rather too quickly. I like and ok with criticisms, however I hope and expect them to be in-depth, not disappointingly this shallow.

samrocksc 5y ago

The cognitive overhead from decorators in TypeScript is the thing I have the biggest problem with. It's just one more differential between onboarding code fast, and having to slog through miles of code to figure out what a decorator is doing.