Proposal: Using decorators instead of extending classes

[ahmed-deftoner]

Most frameworks these days including NestJS and Express + Inversify heavily rely on decorators, so for the sake of convention it also makes sense to use them in our app. It also makes the code a bit cleaner as well. So this:

export interface IPerson extends IEntity {
 name: string;
 age: number;
}

export class PersonEntity extends BaseEntity implements IPerson {
 name: string;
 age: number;
 private _email: Email;
 //...

}

could just be:

@Entity
class PersonEntity {
  name: string;
  age: number;
  private email: Email;
  //...

}

[volf52]

@ahmed-deftoner I did want to use decorators at one point for the similar reasons to the ones you listed above (Some commented out code is probably still present in the @carbonteq/fp package). However, there are two main issues I have with using decorators inside library code:

1- They don't preserve type information of the object they are decorating, which interferes with one of the core principles of library design at Carbonteq, it being type safety. This might have changed in the recent releases as I did see an open issue for it the last time I checked. Let me know what's the current state of things regarding this.

2- Library code design has different considerations than application code design. Any time we have to modify tsconfig.json for a library, we are imposing constraints on the library users. The closer we are to the defaults, the more freedom the users have to configure their project the way they want to / have to. Decorators still require the use of experimentalDecorators flag, and until the benefits of this approach are sufficient enough, I would rather not use them.

Also, the libraries you give the example of use decorators to add reflection metadata to the underlying objects, rather than the macros style of metaprogramming. We have no need of that for now.

In addition to exploring the current state of decorators and their type safety, I would ask you to explore a tool which I think can be quite beneficial for reducing boilerplate and allowing compile time code generation -> https://github.com/nonara/ts-patch. Let me know what utility this tool can provide, and what are the tradeoffs for using it for not only this library but for the projects within the organization in general, be they client facing applications or our internal/open source libraries.

[ahmed-deftoner]

Yes, considering how many frameworks and libraries are using decorators these days. It is still a mystery why they haven't made it a default by now.