fix: allow nullable input objects and arrays #67
Conversation
|
Thanks for submitting - I'll take a look tonight :) |
| @@ -106,6 +111,7 @@ class JSONSchemaValidator extends Validator { | |||
| let typeValidationSchema = { | |||
| $id: `https://mercurius.dev/validation/${typeName}`, | |||
| type: 'object', | |||
| nullable: true, | |||
There was a problem hiding this comment.
I'm wondering if it's better to define nullability on the usage rather than the definition itself so we have a validation schema that fully aligns with the GraphQL schema, WDYT?
There was a problem hiding this comment.
Without this we are technically already still defining nullability on the definition, just implicitly setting it to false, so even if the validation schema contains nullable: true at the point of usage it will fail validation when we send null because the definition itself is non-nullable.
I'm not sure it would be possible to allow objects to be null without this part, unless you have any other ideas how we could do it?
There was a problem hiding this comment.
I think we could maybe do it with an anyOf in this function: https://github.com/mercurius-js/validation/pull/67/files#diff-ee1a5eaed8c16e887653f519f05ddf10825fb4acfe4320521cda3e701825046dR25
That way we only set the nullability when it's applicable - wdyt?
There was a problem hiding this comment.
Ooh that is a good idea, I'll try it
There was a problem hiding this comment.
Sorry for the long wait getting back to you on this!
I've done some investigation and anyOf/oneOf in the spot you described does work to allow input objects to be null without needing this line, but it introduces a a few different issues that I think make this approach unviable.
Firstly, if the object that's being validated has failed on any of the nested fields, it will fail the anyOf check, as it doesn't exactly match the defined object or null, so we get back a lot of extra noise in the error response describing the real issue as nested underneath the failed anyOf check, which I think makes the error harder to understand.
Secondly, if there is a nullable object nested inside the input object, it seems to not be running validation on the fields inside that nested object. I wonder if a conditional schema check has some kind of depth limit? Or possibly I'm missing something with the implementation, but I've tried experimenting with a few similar approaches (like if/else/then) and haven't got this case to work correctly.
I'm all out of ideas for trying to avoid this line, but if you have any more suggestions please let me know and I'm happy to try them out!
There was a problem hiding this comment.
I comprehend the logic behind the removal of L114, but I'm not entirely clear on the significance of opting for oneOf over nullable.
There was a problem hiding this comment.
Apologies for my late reply on this! If the approach isn't viable, I think it's okay to go with your original approach as we are protected by the underlying GraphQL validation :) do you agree with this @mcollina ?
There was a problem hiding this comment.
Got some time this weekend, so gonna have a closer look at this one then :)
There was a problem hiding this comment.
Would love to eventually get this PR merged if you have any time to follow up @jonnydgreen or @mcollina !
|
@peterc1731 Thanks for addressing this fix! |
|
@peterc1731 are you still interested in addressing @jonnydgreen comment? |
Apologies, completely forgot to get back to this one! I will take a look today. |
Fixes #57
When inferring types from the schema, the library does not consider nullability for objects or arrays. The test that validates nullable input types ("should support nullable input type arguments") was only validating string type inputs, when adding validation for a few more input types as I've done in this PR, that test fails.
I've applied a fix for the issue as well as updating the tests, I'm not sure if the approach is the best one, but it works and its a simple change with low impact on the rest of the behaviour.