Deep introduction to class decorators in TypeScript

https://techsparx.com/nodejs/typescript/decorators/classes.html

by kiyanwang • 4 years ago

28 20 4 years ago

jitl• 4 years 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

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

xtracto2• 4 years 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.

davidmurdoch3• 4 years ago

Sounds like you were bitten by Jest inadequacies, no?

dhritzkiv• 4 years ago

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

FinalBriefing• 4 years ago

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

hmillison• 4 years 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• 4 years 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• 4 years 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• 4 years 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• 4 years ago

decorators are better because of scoping imho.

tobr• 4 years 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• 4 years 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• 4 years 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• 4 years 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.

Deep introduction to class decorators in TypeScript

Related Stories