Improve options-handling for input types

[benjaminjkraft]

Right now you can't apply an option, like pointer: true, to a field of an input type, because there's nowhere to put it. So we need to figure out a syntax; maybe just pointerfields: ["field1", "field2.field3"] but that will be a bit of an explosion of options.

We also need to decide how to resolve conflicts: this would mean that two references to the same GraphQL input-type are no longer guaranteed to generate the same Go type, which means we have to prefix the names or something. (This is unlikely to come up within a single query, but more likely across queries.)

As a sort of workaround, you can construct the type inline:

query MyQuery(inputField: String!, ...) {
  myField(input: {
    field: $inputField,
    ....
  })
}

[benjaminjkraft]

Another related problem: you might want to be able to apply omitempty to a particular, or all, fields of the input object. Right now it only applies to arguments. This will actually require new code to handle!

[csilvers]

This is, somewhat surprisingly, turning out to be a non-trivial barrier to genqlient adoption.

I thought of another suggestion, that maybe avoids some of the problems above: allow a user to specify the input fields they're interested in much like (in graphql) they specify the output fields. The code could be something like this:

func QueryMyOperation(...) {
   _ = `# @genqlient(inputFor: "MyOperationName")
   type MyOperationInput {
      email
      # @genqlient(pointer: true)
      validate
   }
   `
   _ = `#genqlient
  query MyOperationName($input: MyOperationInput) {
     user(input: $input) { id }
  `
  genqlient.MyOperationName(...)

Then genqlient would validate that the inputFor is a subset of the actual graphql type MyOperationInput, and that it includes all non-optional fields -- and would generate its own type for this, called MyOperationNameMyOperationInput or something. And that own type would follow the pointer/omitempty/etc directives. And then you could use that type name as an input to QueryMyOperation, or construct it inside QueryMyOperation, or whatever.

[benjaminjkraft]

Oh, that's a neat idea! I'll take a look at how to make it work.

[benjaminjkraft]

As I mention in the above-linked committ, the new bindings option is also a sort of workaround to this.

[benjaminjkraft]

Ugh, I think this is still worth doing, but the syntax is proving to be a mess.

I like Craig's idea above -- which I would modify to saying

fragment InputForMyQuery on MyInput {
  email
  # @genqlient(pointer: true)
  validate
}

# @genqlient(inputs: ["InputForMyQuery"])
query MyQuery(input: $MyInput) { ... }

That has the nice property that it parses, but sadly it doesn't validate (GraphQL doesn't allow fragments on input types, because where would you us them?). We could just disable that validation rule (replacing it with our own less restrictive one, perhaps)? Or we could say you specify it in a comment, like the @genqlient directive itself, but that gets messy because GraphQL has no block-comment syntax. (As does having it be an argument to the genqlient directive, because then it still all needs to be commented.)

Probably the least-bad is to just disable the validator. I don't like diverging from standard GraphQL syntax, but I think it's better than the alterrnatives; if we later find a better way we can add it as an alternative.

[benjaminjkraft]

An amusing bug: this means it's not possible to use the following type in genqlient (you need it to be a pointer):

input RecursiveInput { rec: RecursiveInput }

[benjaminjkraft]

Ok, I've put this off for too long, it's time to just choose the least-bad option.

I think the least-bad option in my mind is basically a variant of my original idea, namely:

# @genqlient(for: "MyInput.myField", <options>)
# <maybe more of these to apply to several fields>

If we come up with a better syntax later it shouldn't be hard to support it as an alternative. It'll be a little work to add support for repeated directives, but I think still easier than trying to get validation right for a fragment-like syntax, and it's a lot less ugly than doing pointerfields: <list>.

We will have to say that your directives must match exactly for all queries with the same inputs, unless you also use typename (this applies too all the approaches except fragments which would effectively require typename).