reflect-metadata VS proposal-decorators

We could use the reflect-metadata library to store the metadata and then scan it manually to replace the placeholders with actual values, but there is a better way.

Second, TypeScript 5.0 cannot emit decorator metadata. Subsequently, it doesn’t integrate with the Reflect API and won’t work with the reflect-metadata npm package.

Database columns will be mapped to domain object properties using decorators. This will include relationships and enum types. reflect-metadata stores metadata about the classes and properties. Most of the work is a simple map for each class, renaming db column properties to domain model properties and vice versa. Reflect.defineProperty holds a list of field metadata on the target class. This is where more database ORM logic could live in the future such as column type, length, etc. A base domain model entity will use this metadata to map the models appropriately.

The Decorators Proposal on GitHub and my previous article on decorators already do a great job of breaking down the basic use-cases of decorators. My goal isn't to recreate those examples there, but instead to highlight some lesser-known features and interactions. Additionally, I'll highlight how to compose or chain multiple decorators on a single class property.

To learn more about decorators, refer to the TC39 Decorators Proposal and explore frameworks and libraries that implement this feature.

First we have a set of TypeScript Decorators (conforming to TC39 proposal) that makes it straightforward to declare API endpoints & assign it to a handler function in a few lines of code:

Although decorators are not yet available in JavaScript, they are actively used with the help of such transpilers as TypeScript, Babel and Webpack. Currently, the decorators proposal is in Stage 3, which means it is getting closer to being a part of native JavaScript. Decorators are the functions, that are called on other JavaScript elements, such as classes, class elements, methods, or other functions, by adding an additional functionality on those elements.

Because many rules are common to many attributes (the coerceType operation is defined by WebIDL, or using similar rules, and the HTML specification defines a handful of microsyntaxes for the parseValue and stringifyValue operations), those could be packaged up in a helper library. And with decorators coming to ECMAScript (and already available in TypeScript), those could be greatly simplified:

Decorators are currently not a part of the standard JavaScript language. They are still being discussed in tc39 and have reached proposal stage 3. This means the spec has more or less stabilized and we can use them but they would be transplied before being run in the browser. This would be done via babel or tsc for most users

JavaScript was created a long time ago, and at the time of its inception, the authors decided not to use affirmative prefixes for boolean names. Now, they do their best by continuing to follow their convention, even if it goes against the community's opinion. Even if the authors wanted to introduce new naming conventions in the specification, they could not do it, at least not coherently. Old code cannot be renamed because JavaScript must remain backward-compatible. And starting to write new code using new approaches is not a great idea either, as there would be two ways to do the same thing, which is also undesirable.

2016-07 – Stage 2. After the decorators proposal reached stage 2, its API began to undergo significant changes. Furthermore, at one point the proposal was referred to as "ESnext class features for JavaScript." During its development, there were numerous ideas about how decorators could be structured. To get a comprehensive view of the entire history of changes, I recommend reviewing the commits in the proposal's repository. Here is an example of what the decorators API used to look like:

The example you've given isn't valid JavaScript, JS doesn't have decorators. (Although there is a stage 3 tc39 for it, afaik no browser has implemented it)

There was a decorators issue brought up in the meeting (issue 508) and decorators metadata, as noted in the article, is now at stage 3. So there's still active work being done on decorators. If I had to guess, I'd say they'd be a likely candidate for ES2024.