You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
peey
changed the title
Design enhancement: a catch-all decorator for modifications to modelSchema (which would subsume e.g. serializeAll)
Design enhancement: a catch-all class decorator for modifications to modelSchema (which would subsume e.g. serializeAll)
Mar 18, 2021
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.
The text was updated successfully, but these errors were encountered: