Null and omitted attributes in InputObjects

[guigrpa]

I want to build a mutation to modify (let's be original) a ToDo object. My hypothetical ToDo object has three fields: whatToDo, notes and assignee, all of them GraphQLStrings. So I define an InputObject type with all three fields:

ToDoInput = new GraphQLInputObjectType
  name: 'ToDoInput'
  fields: -> # all of them nullable
    whatToDo: type: GraphQLString
    notes:    type: GraphQLString
    assignee: type: GraphQLString

My generic mutation will be like this:

UpdateToDoMutation = new GraphQLObjectType
  type: ToDo
  args:
    id:    type: new GraphQLNonNull GraphQLID
    attrs: type: ToDoInput
  resolve: -> # ...

Now let's assume I want to use this new mutation to do the following: "update the whatToDo field and set the assignee field to null, leaving the rest (notes) unchanged". I would love to write...

mutation M {    // [incorrect GraphQL]
  updateToDo(id: 3, attrs: {whatToDo: 'whatever', assignee: null}) { ... }
}

...that is: explicitly including assignee: null to nullify that attribute, and omitting notes to leave this attribute as it is. But unfortunately the spec (and @leebyron's Slack remark confirms it) says null values can only be modeled by leaving the attribute out, colliding with my other semantic needs: omitting an attribute to just not touch it.

Any chance the spec might support null as a valid literal value? (Otherwise: what other options are there to implement such a generic mutation?).

[will-weiss]

Perhaps you could accomplish this using

UpdateToDoMutation = new GraphQLObjectType
  type: ToDo
  args:
    id:    type: new GraphQLNonNull GraphQLID
    set: type: ToDoInput
    unset: type: new GraphQLList(GraphQLString)
  resolve: (root, args)->   # ...

then you could write:

mutation M {
  updateToDo(id: 3, set: {whatToDo: 'whatever'}, unset: ['assignee'] { ... }
}

achieving the desired goal within the bounds of the language specification.

[leebyron]

The primary issue here is that most environments do not distinguish between null and undefined in the way JavaScript does. Since GraphQL is designed to be a thin layer atop many different environments, we can't always support the distinction.

I think @will-weiss's suggestion is closer to what you want. To explicitly declare the things you are removing in a mutation.

[leebyron]

One change that I can make that should make working with APIs that treat null specially is to also omit the not set object properties on the internal value.

[guigrpa]

Yes, the workaround is really nice. I got it going without problems, thanks a lot for the idea. Regarding the reason behind the spec, I understand better now - but it's a pity I can't use a cleaner API considering that I have JS on both client and server.

On Tue, Aug 11, 2015 at 10:23 PM, Lee Byron notifications@github.com
wrote:

One change that I can make that should make working with APIs that treat null specially is to also omit the not set object properties on the internal value.

Reply to this email directly or view it on GitHub:
#112 (comment)

[leebyron]

2734d01 and 44c9daf implement the change that omits properties from arguments and input objects that were not provided, rather than their previous behavior of being set to null.

Hopefully this change will help when being paired with APIs which treat null differently from undefined.

[leebyron]

These changes will go out in the next version release.