Allow custom toJSON method on class for serialization. about structure

[wenderjean]

In my opinion, the static method toJSON seems more a kind of callback that should actually be named as afterSerialize or something like that, but, we can fall in a lot of problems dealing with this approach since it doesn't matter the feature you're gonna be dealing with the serialization will be always compromised to the behavior declared in afterSerialize.

The second point is, it will assume that the structure model should do more than it is proposed to do, for example, to harbor unnecessary business serialization logic.

I agree with @talyssonoc that complex serialization should live in a serializer layer and this feature will just add complexity to solve a problem more related to architectural design.

[talyssonoc]

Hello, @loweoj, sorry for the delay on answering this issue. I really like the idea, but I'm not convinced yet the name should be toJSON since it already receives the output of the serialization 🤔, did you think of any alternative name?

[talyssonoc]

Actually, after discussing with some other contributors there are some raised concerns about it:

• Serialization is not the main goal of this lib, and in case some deeper rules for serialization are needed they should be built outside of the structure, like a UserSerializer.serialize(userStructure)
• If we ever add this option, this should not be a static method, the idea of using a decorator is exactly to avoid polluting the class with non-business logic
• Right now our validation process depends on serialization so we can pass POJOs to Joi, this should be taken into consideration to avoid confusion during validation

After considering these points, I'm not sure anymore if we should add this feature.

[loweoj]

Yup makes sense. Thanks for the input guys.