Hello! I am confused about something in the docume...

# apollo-kotlin

[Eduard Boloș]

Hello! I am confused about something in the documentation, more specifically here:

By default, the GraphQL spec treats nullable variables as optional, so it's valid to omit them at runtime. In practice, however, this is rarely used and makes the operation's declaration verbose.

I am not sure that the "so it's valid to omit them at runtime" is actually true. Looking at the linked spec, if hasValue is is not true, and defaultValue doesn't exist, there's no value coercion happening. Which will lead to an error – that's exactly what we are experiencing with our Python server that uses Strawberry. Instead, what we are seeing is that we can omit the nullable variable only if there is a default value defined for it in the schema, which is not clear in Apollo's documentation. Am I making sense? 😄

[mbonnin]

That is one of my most dreaded parts of the spec 😅

[mbonnin]

I guess it all depends what you call "valid", agree the docs could be more clear there.

[mbonnin]

To our defense, I think the spec isn't 100% clear either...

[mbonnin]

Let's take an example:

type Mutation {
  // Modifies the user name and returns the new name
  modifyUser(name: String): String
}

[mbonnin]

mutation ChangeUserName($name: String) {
  modifyUser(name: $name)
}

[mbonnin]

It's perfectly fine to not set name in your variables

[mbonnin]

The resolver will receive undefined and can decide what to do. Most probably, it will just leave the user name unchanged

[Eduard Boloș]

In our case, the server blows up 😅

TypeError: mutate_foo() missing 1 required positional argument: 'argName'

We can easily avoid this on our part with a linter rule to require a default value on all nullable variables, but this was surprising and seems to be a mismatch somewhere between the expectation and reality 😄 So I thought of flagging it, as the docs seemed confusing.
But it's also the page for migration to the old V3, so not sure if it's worth updating it now, although this was the only place in the documentation I could find anything being discussed on the topic.

[mbonnin]

This is probably better fixed in your server resolver. There may be some valid use cases for providing undefined

[mbonnin]

There are some thoughts about improving the type system for inputs but it's probably not for tomorrow

[Stylianos Gakis]

Isn't this used for scenarios where you may have a mutation which takes in many parameters?
Let's say we have a mutation which is called editUser and takes in a name and lastName as parameters.

Let's say name is a nullable String

Omitting the value means don't change it at all
Sending null means make the name be null
Sending not null means set the name to the input

So if your server doesn't support this functionality, it feels like the server is the one at fault here, right?

[Eduard Boloș]

Oh, sorry, should've actually said that this is for queries not mutations, but probably the same absent != null semantics should be there, so probably that's a distinction without a difference 😄
Thanks for your inputs!