Allow custom toJSON method on class for serialization.

[loweoj]

This feature would allow you to specify a static toJSON method on the instance that would be called with the serialized JSON. It would allow you to modify the JSON before being output. Adding removing and modifying attributes to the final output.

e.g.

var User = attributes({
  name: String,
  age: Number
})(class User {
  static toJSON(json) {
    json.someProp = true;
    return json;
  }
});

const user = new User({
  name: 'John',
  age: 42
});

expect(user.toJSON()).to.eql({
  name: 'John',
  age: 42,
  someProp: true
});

It should also work on nested structures:

var Book = attributes({
  title: String,
})(class Book {
  static toJSON(json) {
    json.added = '123456789';
    return json;
  }
});

var User = attributes({
  name: String,
  age: Number,
  favouriteBooks: {
    type: Array,
    itemType: Book
  }
})(class User {
  static toJSON(json) {
    json.name = 'Hello ' + json.name;
    return json;
  }
});

const user = new User({
  name: 'John',
  age: 42,
  favouriteBooks: [new Book({ title: 'Jack' })]
});

expect(user.toJSON()).to.eql({
  name: 'Hello John',
  age: 42,
  favouriteBooks: [{
    title: 'Jack',
    added: '123456789',
  }]
});

[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 :thinking:, 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.

[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.

[loweoj]

Yup makes sense. Thanks for the input guys.