Closed william1616 closed 1 year ago
Hey @william1616 thanks for fixing this issue I will take a look into this pr next week, when I'm back from vacations
Hey @william1616 I've just pushed a new release (v0.0.13) with your fix
Thanks for contributing to this project
Thanks @G4brym
Currently the request body validation will attempt to validate all properties on an object in the request body regardless of if that property is set or not
For example with this schema definition
You would expect that the request body below would be valid
However it's not and the below is returned from the validator
The problem is that the validate() function on the Str parameter first performs the below logic
Which doesn't work if the value is
undefined
Interesting at the top level the Body class (which is used to validate the request body) checks the below logic before validating
Which, if a value is
undefined
(ornull
) will set it to it's default value (assuming that's set) and then if the value is stillundefined
ornull
throw anis required
error rather than attempting to validate itI've implemented similar logic in the Obj class's validate function however unlike in the Body class if there a value is
undefined
and has a default value is not changed and remainsundefined
. Whilst for Parameters setting a default value if the value isundefined
makes sense it does not make sense for an object. I originally encountered this issue building a PATCH endpoint into an API. If you consider the belowFirst a request body definition with a default value
First a POST Request to create a Task
Then a PATCH Request to update the Task
You would expect the Task to look like
However if the default setting logic was implemented then actually the Task would look like this
With this change
undefined
non required values will not be validated andundefined
required values will return anis required
rather thanCannot read properties of undefined (reading 'toString')
error. (I've used Str as an example in this PR but the concept applies to bools & numbers as well