Don't error if optional field not present

[deoqc]

Sometimes I have a form with not all fields required, and it will be used as inputs to a mutation.

const query = gql`
  mutation myForm(
    $name: String!
    $tags: [String!]
  ) {
    createSomethingAwesome(
      name: $name
      tags: $tags
    ) {
       id
       someField
    }
`

But I actually need to pass an empty tags to variables. If I pass only variables: { name } it will error.

Should apollo-client take care of this?

Right now I'm doing variables: { tags: [], ...formFields } instead of variables: formFields since formFields won't have tags key if it is empty.

[stubailo]

I don't think Apollo Client should take care of this. IMO the correct way to solve this is to pass tags: null as a variable. Is that an acceptable solution? I consider this a limitation of GraphQL itself, rather than Apollo Client, and the workaround doesn't seem so bad.

[stubailo]

Perhaps we could analyze the variables and automatically pass null for ones that the developer doesn't pass, but I think that would actually be worse than the current behavior, which at least warns you when you forget to pass a variable.

Although, perhaps we could use the nullability ! to determine if we should pass null by default.

[deoqc]

Yeah, the thing is the field is optional and if you don't pass it is not warn, it is an error.

I can always pass the empty/null args, as I am doing now, but I wondered if wouldn't it be a feature apollo-client would like to have. I have no argument against if you think that wouldn't.

[stubailo]

My only reservation is that it's more code to maintain, so if it's not super valuable it might not be worth it.

[kojuka]

Heres how we approached it. Not sure this is correct but it solved that issue for us.

We found that we needed to change our mutation schema on the server to use GraphQLInputObjectType: More info here: http://graphql.org/docs/api-reference-type-system/#graphqlinputobjecttype

Then in your mutation schema you'd define formInput as a GraphQLInputObjectType. Finally client side your mutation would look something like this:

mutation myForm(
    $formInput: formInput!
  ) {
    createSomethingAwesome(
      formInput: $formInput
    ) {
       id
       someField
    }

Hope that works.

[deoqc]

@webular it's a good approach, just tested and it works.

But I usually prefer just use GraphQLInputObjectType when some input just make sense when grouped (like geocode={lat, lon}), but it clearly shows that if you really want this feature, you could get it somehow from the GraphQL specs.

I think I can close it now @stubailo .

[stubailo]

OK, works for me!

[deoqc]

I don't want to be annoying but just saw that graphiql doesn't error in my situation above, I think it is a apollo-client trait.

[stubailo]

Ok in that case it might be a bug.

[deoqc]

Any update about this (possible) bug?

[helfer]

@deoqc This is not a high priority for us at the moment, but if you submit a PR with a failing test case, it would help us fix it faster.

[deoqc]

Ok will look into it.

Just asked 'cause it is annoying/error prone to always fill missing optional variables, and have this inconsistent behaviour between apollo and graphiql.

[glasser]

I've been reading the GraphQL spec and it doesn't really seem clear about whether or not leaving off the value for a variable which is null is allowed or not. However, the NOTE in https://facebook.github.io/graphql/#sec-Null-Value does suggest that it should be allowed:

The same two methods of representing the lack of a value are possible via variables by either providing the a variable value as null and not providing a variable value at all.

[glasser]

Although maybe this is a duplicate of #852, which refers to graphql/graphql-spec#83 which only added the concept of null-ness to GraphQL after the discussion in this issue!

[helfer]

@glasser: yes, this is something that I will need to add to the 1.0 roadmap. Thanks for the reminder!

[helfer]

Closing this in favor of #852