List of frameworks using decorators

[zenparsing]

Is there a list of JS frameworks that are currently providing decorators or documenting usage with decorators?

[littledan]

Not that I know of. This sounds like a good idea for documentation, if anyone is interested in making a PR.

[hax]

Yeah actually I asked someone where is the use cases of changing placement except @bound (actually a sound implementation of @bound not change placement but add extras), and he said I should ask the champions of decorators and none of his business.

[littledan]

Another change of placement between "instance" and "own" is the @observed/@tracked decorator, e.g., as Glimmer has. I don't have a good use case for switching between static and instance-related, though. If there's some particular reason to lock that down, I'd be open to it. Right now, in general, decorators let you replace any class element with any other, so it's not clear exactly how to describe the limitation.

[hax]

@littledan Have no idea about "instance". The document only have "static", "prototype" or "own"...

Let me guess... for PrivateName?

[littledan]

The current spec uses prototype/own, but I am wondering if unifying this as instance could be more intuitive for decorators authors. But, this is a bit off-topic, I just need to make progress on that change and propose it elsewhere.

[hax]

Ah? You mean replace prototype by instance ? Don't understand...

[littledan]

@hax Yes, replace both prototype and own by instance, and say public methods are on the prototype and fields are own (just like in syntax). I don't think the current "generality" actually buys us anything, and is just confusing. See discussion at https://github.com/tc39/proposal-decorators/issues/180#issuecomment-446876704 (yes, it does tie in with private).

[hax]

@littledan Sorry it's not easy for me to understand what #180 for. But it seems now we can not change the placement of own/prototype? And as you said, there is also no use case of change placement of static/non-static, so we can just drop the placement (maybe only provide isStatic)?

[littledan]

@hax Yeah, sorry, #180 is not very clear; I'll get back with a PR that has a clearer commit message. I'd rather use a string value than a boolean just for readability and future extensibility. My thinking is: If you want to make a prototype field, you could use a static initializer/"starter" for it; if you want to make an own method, you can use a field for that. The current design is a bit redundant, causing extra complexity both for JS developers and engine implementers.

[hax]

@littledan Actually I never think change fundamental semantic is a good usage of decorator, so I think it's great.

for readability and future extensibility

Is there anything we want to add in future?

[littledan]

There are lots of things we might want to add in the future. See the v2 label in this repo.

[hax]

@littledan Do you mean "follow-on proposal" label? I made a glance at the list, but do not have the idea which one will add new placement value.

[littledan]

Sorry, yes, that label. And I misunderstood, I thought you meant follow-on proposals in general. I don't have any ideas for other placements, but this is a general "best practice" in JavaScript API design. e.g., see https://w3ctag.github.io/design-principles/#string-constants

[hax]

@littledan I understand this rule prefer string over enum (integers), prefer dictionaries over bitmask. So not directly apply to our case

• placement: 'instance' | 'static'
• static: true | false

I prefer static: true | false because many novice do not use instance, just use object 😂 , and most programmers never know what is placement (actually I misspell it several times 😅), but everyone know static because it's a keyword. So static: true | false is a much easy API to learn, especially for those non-English programmers.

[littledan]

You like static better than isStatic? (Me too.)

[hax]

isStatic is ok, but it seems static follows name convention? isStatic more like a method name I think.

[ljharb]

If we have a “static” boolean, would it be an error to specify both that and “placement”? Or, how would “instance” be specified?

[hax]

@ljharb It seems @littledan means do not allow change placement so we can only provide information use boolean. Maybe I misunderstand @littledan ?

[littledan]

I think the idea would be that static replaces placement.

[ljharb]

Is there a separate thread to discuss this? This one is about listing frameworks that use decorators; i'd love to discuss whether it's a good idea to restrict placement options, but i don't want to derail this thread.

[pabloalmunia]

Is there a list of JS frameworks that are currently providing decorators or documenting usage with decorators?

We are working into a very powerful framework with decoratos: https://chameleon.origami.works/

A list about this kind of frameworks and libraries is a very good idea.

[kt3k]

We've been creating DOM programming library which uses decorators for binding methods to events, binding query selectors to fields etc. https://github.com/capsidjs/capsid

Our decorators now conform to babel 7.1+'s new decorator implementation.

[littledan]

In the Stage 3 presentation for TC39 in a week, I'd like to include:

• A list of frameworks that are using or are looking into using decorators
• A list of frameworks that have experimented with the Stage 2 decorators developed in this repository

If someone could compile this list, it would be really helpful.

[isidrok]

Here's a list of the frameworks/libraries I can think of off the top of my head, most of them if not all use TS decorators that can be used with the babel plugin in legacy mode:

• Angular
• lit-element
• Polymer through Polymer-decorators
• TypeORM
• Nest
• tsoa
• Stencil
• Ionic
• MobX
• InversifyJS
• aspect.js
• LoopBack 4
• ember-decorators (this one uses the current proposal and is written in JS)

And here is a list of packages depending on @babel/plugin-proposal-decorators more extensive than the npm one.

this project seems quite interesting and supports both proposals.

[littledan]

@isidrok Thanks! I've copied this list into our draft presentation for TC39.

[Lodin]

I would like to add my framework to this list as well. Still WIP, but I believe not for a long time. Corpuscule

[littledan]

Added Corpuscle.

[hax]

It seems many libraries still use the legacy decorator proposal.

[buschtoens]

@hax https://github.com/tc39/proposal-decorators#how-should-i-use-decorators-in-transpilers-today

[glen-84]

I started a publicly-editable Google spreadsheet – List of frameworks/libraries using decorators.

I added the following to those previously mentioned:

• Aurelia
• TypeGraphQL
• Vue Class Component
• Vue Property Decorator

Feel free to add others (just keep the formatting the same).

[pzuraq]

We are past the information gathering stage that this issue was opened for, so I'm going to close it for the time being. If we need additional information about modern framework usage, we can reopen.