Global omitempty option

[liron-navon]

Let's say a graphql query accepts an input object, which has an optional string in it, if I use the input object, and not give a value to that string, it should be committed, that's just how graphql works.
Unfortunately, this library doesn't work that way.

Is your feature request related to a problem? Please describe.
I have this input for shopify, the non struct fields are not required

The generation works well, but if In don't include the optional fields, genqlient turns them into null (when defining value as pointer) or to an empty string (when defining value as value).

They should just be omitted as I don't want to send them, otherwise shopify will fail to use this.

Using the "@genqlient(omitempty: true)" is impossible, because the import is required, even tho every field on it is optional.

Describe the solution you'd like
add to the settings.yml file an option "omitempty: boolean" that would just cover all the json fields.

Describe alternatives you've considered
Adding manually the "omitempty" directive, but with thousands of fields it's makes it really hard to use, and time consuming and prone to humen errors.

Additional context
What I get generated, why would an optional pointer to a string not have omit empty?

[benjaminjkraft]

Check out the optional: pointer setting in genqlient.yaml! If I'm understanding your request correctly that's exactly what it does.

[liron-navon]

@benjaminjkraft why did you close it? you don't understand correctly, the "optional: pointer" doesn't omit empty, it passes "null" instead, this breaks different apis, namely "shopify" and "spacex"

[benjaminjkraft]

Thanks for clarifying. I guess it's valid GraphQL to treat explicit null differently. It seems like what you are proposing is a global config to turn on omitempty. That seems reasonable to add, although soon we are going to have to figure out how to make all these related config options not explode the config complexity.

[mujagic-nermin]

Looking at the documentation, I'm trying to achieve what it says here with the global omitempty.

Doesn't seem to be working for my code, even though I followed exactly?

Where is the ,omitempty json tag??? Below is my genqlient.graphql

[dharijanto]

Thanks for clarifying. I guess it's valid GraphQL to treat explicit null differently. It seems like what you are proposing is a global config to turn on omitempty. That seems reasonable to add, although soon we are going to have to figure out how to make all these related config options not explode the config complexity.

Hi Benjamin, just to clarify, I think the author wants the global omitempty: true only for input parameter. He is probably using Hasura 2.0 (just like I am)

Just to give you a bit more background, in Hasura 2.0, they introduced a breaking change that distinguishes "implicit null" vs. "explicit null".

hasura/graphql-engine#7484 (comment)

[dharijanto]

Hi @benjaminjkraft I created a draft PR to fix the issue. Would you mind taking a look?
#264

I haven't written/fixed tests associated to it, I figure I'd check with you first if the direction is okay.

[benjaminjkraft]

Thanks for the context and the PR. I can see why they have ended up wanting the distinction. (For others reading, the changelog entry describes the breaking part of the change, although it sounds like this isn't the only place they draw the distinction.)

I commented in the PR -- for a couple reasons I think a new config option might be useful but I think if we do do that it's a fine way to do things.

At some point we should probably also have a clearer example/FAQ entry for how to use genqlient with hasura, since the hasura-generated schemas seem to have a bunch of quirks that genqlient's defaults don't match with. (But that doesn't have to be now.)

[benjaminjkraft]

One realization I had on the way home: a workaround is to have your inputs be the fields you want to set, rather than the whole object. For example, instead of:

myQuery(myInput: SomeInputType) {
  field(input: $myInput) { ... }
}

you'd do

myQuery(myField: String!) {
  field(input: {myField: $myField}) { ... }
}

Obviously some pluses and minuses there, so it doesn't obviate the issue, but may be useful until we get this option sorted.