Open Abion47 opened 7 months ago
I've designed the tags.Default<T>
for only swagger documentation, but it seems good idea.
However, I am not sure that the function of assigning default values is necessary only in parse, and the names of functions, such as validateParseApplyDefaults<T>()
, become too long and complicated.
I wasn't sure about the convenience functions and only really included them for completeness. I would imagine that this feature would either work implicitly for everything that supports in (in which case those functions are redundant) or would be an optional addition (in which case those functions are extraneous). In either case, they are definitely riding the edge of being too wordy to be practically useful.
As far as for where the default field population would occur, my thinking would be that it would work everywhere that validates an input and returns a confirmed object of the type. This would mean assert
, validate
, and the parse
family of functions. The http
functions and protobuf.decode
almost certainly should populate default fields as well considering their purpose, while clone
and prune
it probably shouldn't as it would fall outside of their intended use case. As for random
, any field with a default value should never be null/undefined, and instead should randomly flip between a randomly populated value and the default value.
The biggest exception would be is
, whose role is merely to look at an object and return a boolean indicating whether or not that object already satisfies the type. In this case, mutating the object itself with default values would be an undesired side-effect. (What this means for isParse
is less clear, but ultimately I think it shouldn't mutate the object either to maintain feature parity with is
.)
Feature Request
When creating my data models, I make ample use of tags to make them easily serializable into a JSON schema format. Another feature I use are the validation and parsing functions, but I have noticed that they don't seem to respect when a field has the
Default
tag.I would've expected that when I run a validator on an object or a parse on a valid JSON string that omitted a field marked with the
Default
tag, the validator/parser would self-insert the specified default value for that field. This is especially true for parser functions, where the common use case is to validate user input and I would expect omitted fields with default values to be automatically populated.I'm not sure if the desired approach should be to mark the field with the default value as optional or not, so I will include expected behavior for both approaches:
Example (Required Field)
Current Behavior
Expected Behavior
Example (Optional Field)
Current Behavior
Expected Behavior
Alternative Solution:
applyDefaults
FunctionIf for whatever reason it is undesired or overly complicated to bundle this functionality into the existing parsing and validating functions, an alternative solution would be a new function that analyzes the missing optional fields of an object and supplies any default values from the defined tags:
Definition
Usage