Open MatthiasKunnen opened 2 years ago
I understand GraphQL cannot distinguish between nullability (null) and optionality (undefined) in its generated spec/documentation and that this has the potential of confusing the consumers of an API that differentiates between the two.
Exactly. Without a proper layer for transforming input fields, all we can achieve is a false sense of type correctness. In runtime it will work the same.
This feature request does indeed require the ability to transform input fields for option b or the ability to validate (throw errors) for option a.
Is your feature request related to a problem? Please describe. I'm trying to create a Mutation that allows partially patching an entity which has required fields. Example entity:
My current input type for this entity is
Taking the
description
field as an example, mutations can eitherNow this all works marvelously for an optional field. However, for the
name
field it should not be allowed to pass null as the field is not allowed to be cleared.Describe the solution you'd like
I would like the
nullable
property of the@Field
decorator to feature an optionoptionalOnly
which would result either a) an error being thrown onnull
or b)null
properties being deleted. This would result in the following input type:I understand GraphQL cannot distinguish between nullability (
null
) and optionality (undefined
) in its generated spec/documentation and that this has the potential of confusing the consumers of an API that differentiates between the two. However, I believe that this use case is a valid one.Describe alternatives you've considered
I've looked into the possibility of using custom validators and
class-validator
to accomplish this but have not found a way so far as I'm not really trying to validate a value but rather, change it.I had a look at the code of
type-graphql
but have not been able to estimate the time required or impact on the code base of this feature.Additional context
Potentially related to #340 (transforming input fields).