Deep introduction to class decorators in TypeScript | Hacker News Reader

Deep introduction to class decorators in TypeScript

techsparx.com

28 pointskiyanwang20 comments

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

So, beware libraries or frameworks that rely on this toolset.

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.

Sounds like you were bitten by Jest inadequacies, no?

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#?

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.

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.

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?

Because there is something wrong happening while the transpilation of the non-standard feature is happening.

I use NestJS with Jest just fine. Lots of decorators, too. What bug did you encounter?

Yea, it makes me really worried about Angular's future updates given its heavy usage of decorators.

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.

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.

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?

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.

decorators are better because of scoping imho.

> 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.

Yeah: in a very real sense the "original sin" here was introducing (nay: forcing) class syntax to JavaScript, a language which at its core doesn't even naturally use/model classes (as it was designed around prototypes); all of this other complexity is the language falling downhill in an attempt to merely regain functionality for this new syntax that was previously trivial when you simply assigned "methods" directly to your prototype with the = operator (and so making it obvious where you would add a normal function call to functionally compose behaviors instead of needing a "decorator").

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.

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.

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.

Reply on news.ycombinator.com