Why use decorators to declare methods? about typegoose

[szokodiakos]

Hello. When Typegoose was created I wanted an explicit decoration flow. It would feel a bit odd that when you define a function it automatically becomes a static or instance method.

In my opinion explicitness is a bit better here since props must to be defined with decorators.

Also this gives room to create helping methods which are not part of the schema. (I can't think of a use case actually.) Also it could be done the other way around like defining an @ignore decorator for methods.

I would stick with explicitness.

[MichalLytek]

Looks like all we need to do in typegoose is to register class fields. All virtual, instance and static methods can be collected by loadClass() helper function:
http://mongoosejs.com/docs/advanced_schemas.html

[MichalLytek]

It would feel a bit odd that when you define a function it automatically becomes a static or instance method.

It would feel a bit odd that when you call the method of a model/document and you will get undefined is not a function, because current types just do the & with the class definition, so TS thinks that it have all methods and props from the class are available.

If you really need to exclude some methods, you can make this private (so no public type available) and decorate with @privateMethod.

[MichalLytek]

Yes, it should be handled automatically:

const staticPropNames = Object.getOwnPropertyNames(ClassType);
const instancePropNames = Object.getOwnPropertyNames(ClassType.prototype);

All you need to do it to filter lenght, prototype and name from staticPropNames and constructor from instancePropNames.

[nikis05]

@szokodiakos Thanks for your kind response. I see the point, but I assume that adding some magic at the cost of a one more layer of implicitness is something this library is expected to do. Defining schemas manually is also more explicit than inferring them from typescript metadata, but i prefer the latter, that's why I'm here.

On the other hand, explicitness can be understood as

doing what is expected to be done

and by extending the Typegoose base class I clearly express my intention to use the class as a template for building a schema. I can hardly imagine a usecase when the possibility not to add a method to the schema would be required, while this method wouldn't be accessible from the scope of a model. I think, simple things should be done simply, leaving space to use some workarounds in more rare and complicated cases.

[nikis05]

The @prop decorator is meaningful, while it can be used to configure props. On the contrary, @staticMethod and @instanceMethod only add some notional duplication.

[szokodiakos]

All right, the last argument bought me, however this will be a breaking change.

Currently theres a feature/4 branch which includes some breaking changes. I would like to release all these stuff together.

[szokodiakos]

wow I haven't heard about that utility function. This really removes the need of any decorator except the property ones.

[x3ro]

Mmh was this abandoned? I just ran into the same odd issue where I forgot a decorator, TypeScript was happy and then I got a missing method error at runtime :(

[hasezoey]

Mmh was this abandoned?

All important comments on that:
#48 (comment)

#48 (comment)

#48 (comment)

currently its a "won't fix"

(and @szokodiakos has "left" the project, and so left the branch feature/4, where it wasnt implemented, but i made in #356 a vote about continuing feature/4 for release 6)

[hasezoey]

this is included / removed in v6.0.0

@Ben305 this can be closed