The returned value could just be deep-merged into the model-schema as built-up by field decorators.
It does not save many characters of typing, but it's a much more uniform interface for the library user. Of the two interfaces offered by the library (decorator-based and non-decorator), it'll be ideal if the user using one of the interfaces doesn't have to deal with the other.
serializeAll
is not the only case which is insufficiently supported by class field decorators.factory
is another case. Without decorator support, this is what the user has to write:but with decorator support, this is what user may instead write
But this got me thinking, shouldn't there be just one class-decorator to support both of these?
The returned value could just be deep-merged into the model-schema as built-up by field decorators.
It does not save many characters of typing, but it's a much more uniform interface for the library user. Of the two interfaces offered by the library (decorator-based and non-decorator), it'll be ideal if the user using one of the interfaces doesn't have to deal with the other.