[client] using Optional Undefined Arguments

[FidasL]

Hello.

I have question about using Optional undefined arguments. I see this section in documentation, but if I understand correctly, this section is related only to schema generator on server side. In our project, we use both, graphql-kotlin server and client. In server side, we chose verifying nullable arguments using DataFetchingEnvironment.containsArgument()

My question is, how to use Optional arguments on client side? Client generator always generates data classes like this:

data class PersonInsertInput(
    val id: Long? = null,
    val name: String? = null

So, when I use this data class variable in request, Instead of undefined name argument, there is always null value. Is it possible to somehow configure generating of GraphQL data classes, or are we doing something wrong on client side? This problem is mainly with update mutation, where server updates all missing values to null, what is for us an unexpected behaviour

[dariuszkuc]

Hello 👋
Currently undefined arguments are not supported by the graphql-client

[smyrick]

@dariuszkuc I still don't understand. There is no such thing as undefined client arguments. The code is generated from their query file so if they don't want that field to be requested or argument passed in, it should be removed from the query file

[FidasL]

@dariuszkuc , @smyrick thank you for your response!

My use case is for example to update record in database. I send mutation with properties that should be updated. If we have record, that has got 20 properties, I have to name or skip each property. With this example, I need to have custom mutation each time, when I want to update record (sometimes, I want to update one property, another time, I want to update the other...

Better solution would be not to name all properties individually, but define one UpdateInput data class with variable set of properties (some of them should not be interpreted as null). It is possible for example in Javascript clients, where these properties could be undefined and they are not send in the graphql request. With graphql-kotlin client, if I don't explicitly define any property, it is declared as null, so my server interprets this that I want to update property to null value.

We know, that we can define all graphql variables as nullable and don't include them in request, but it would be better to change them programatically. For example, when our graphql schema changes, it wouldn't be necessary to change .graphql request.

I understand, that this could be a problem with Kotlin type-safe behaviour, but I think this could be good, usable feature that simplifies work with client and writing graphql requests.

[dariuszkuc]

edit -> too slow... what @FidasL wrote ⬆️
original reply below

---

It is all about parameterizing queries - given two optional arguments to bar why would you write 4 different versions of the mutation instead of parameterizing it? (similar argument could be made for FooInput mutations)

type Mutation {
  foo(input: FooInput!): Foo!
  # optional input string and/or int
  bar(optionalString: String, optionalInt: Int): Bar!
}

# input has optional fields
type FooInput {
  id: Int,
  value: String
}

// rest of the schema omitted for clarity

[smyrick]

Ahh ok I see now.

So you want a single graphql query file like so

mutation UpdateData($customInput: CustomInput!) {
  updateDataWithInput(input: $customInput) {
     # ... unrelated response selection
  }
}

And CustomInput has a bunch of properties, and based on different client states, you decide which ones to pass in, but this allows to the reuse of the object and query file

input CustomInput {
  requiredField: String!
  optionalOne: String
  optionalTwo: String
}

So today you are force to construct the entire object client side and using the Kotlin default params it sets not passed in params as null.

val input = CustomInput(requiredField = "foo")

input.optionalOne // null
input.optionalTwo // null

But to the server API it looks like you explicitly passed in null and not undefined.

---

Hmm yea so this is not supported today. It looks like most other client libraries handle this by wrapping every single input with some kind of Optional object (like apollo-android. With Kotlin defaults we could have things default to undefined. But that would still require that all optional inputs be wrapped in this class. That would be a big breaking change

[dariuszkuc]

Created #1151 to track this.

[smyrick]

Created #1151 to track this