OptionalInput non-nullable generic

[Sachanski]

I saw in the documentation that

Regardless whether the generic type of OptionalInput is specified as nullable or not it will always result in a nullable value in Defined class, i.e. OptionalInput will appear as nullable String in the GraphQL schema and in the wrapped value.

My question is - is this behaviour going to change to the more intuitive "if I pass a non-nullable I expect the value to also be non-nullable - i.e. to match the provided type" or are there some signifcant technical difficulties that are preventing this?

[dariuszkuc]

Hello 👋
Think about what OptionalInput is supposed to represent, i.e. it is an optional value which can be present or not. Due to the reflection limitations, we cannot currently support default values. Therefore it is currently not possible to define non-nullable optional value as you cannot set default value*.

*you could try to use the hooks to modify the schema and/or transform the schema after it is build but that is not a built-in functionality.

[Sachanski]

It might be that I am interpreting OptionalInput differently. i.e. the input is either defined or undefined (as are the names of the sealed class inheritors) and that should have no bearing on the actual value type (which can be nullable or not). Anyways as I sort of suspected there are some technical challenges that prevent achieving this behaviour - thanks for the answer.

[tuomax]

I came looking for discussion on this topic, hoping there was something planned for more robust handling of optional-but-not-nullable types. We use OptionalInputs a lot, but more often than not, null is not a valid input. We do have guards in place, but they are explicitly defined, and I fear nulls might slip through some validation cracks.

Note that these are not cases where we would like to define default values—we are quite happy with having OptionalInput.Undefined values, but the Defined ones just should never have a value of null.

I don't think even GraphQL spec includes a way to define an input field as "omittable non-null without default", so I understand this isn't a priority, and I get it why OptionalInput works the way it does. Still, I wish the library provided something for this use case. Having OptionalInput<String> and OptionalInput<String?> behave differently is probably not an option anymore, or even technically possible.

Maybe a different type altogether, NotNullOptionalInput<String> (horrible name, I know) that would fail in validation if the client explicitly sent a null? Of course it's not quite that simple, as the client would need to be made aware that the field doesn't allow nulls (maybe a directive?), and maybe the error message would need to be configurable etc.

Anyway, at least in our project we've thought it would be great to have better support for non-nullability in a Kotlin-first GraphQL approach. Do you have any thoughts if this could be improved somehow?

[dariuszkuc]

@tuomax AFAIK currently there are no plans to support NonNullOptionalInput<T>. I believe you should be able to achieve this sort of behavior either through custom hooks or maybe some custom directives.