Support resolve on Input types

[wmertens]

Update: see #747 (comment)

Creating an API for reading data is easy now, thanks in part to per-field resolvers that allow you to map from server-side domains to the client domain in a piecewise manner. However, there is no corresponding function to go from client to server domain.

How about adding unresolve(root, args, context, info) to the field definition?

I think it would make sense if it was allowed to mutate root, and it would return the server-domain value of its field. So this would enable:

1. re-packing/mapping fields:

const Foo = new GraphQLObjectType({
  name: 'Foo',
  fields: {
  	items: {
  		type: new GraphQLList(GraphQLString),
  		resolve: ({items}) => items.split(','),
  		unresolve: (_, items) => items.join(','),
  	},
       },
   })

2. renaming fields:

const Foo = new GraphQLObjectType({
  name: 'Foo',
  fields: {
  	niceName: {
  		type: GraphQLString,
  		resolve: ({badName}) => badName,
  		unresolve: (root, value) => {
                        root.badName = value
                        delete root.niceName
                       }
                   }
  	},
     },
   })

Right now, to do this, you need to manually traverse the input arguments to apply the transformations where needed.

[leebyron]

From what context would this unresolve function be called?

There should be nothing stopping you from adding these functions to your schema, but I'm not understanding what code should be calling them.

[wmertens]

Hmm, in my example I was envisioning a world without input objects it seems :) pretend that the above types are InputObjects with unresolve and the resolvers are what is used on the corresponding output types.

The idea is that unresolve is called depth-first on the inputs of a mutation, so that the mutation resolver gets the arguments as already-mapped-to-server-domain arguments.

Graphql knows the schema much better than the dev and if you are using complex inputs it gets easy to forget to reverse the client mapping. Plus, if you manually call the unresolvers, you also have to do it depth-first, which gets hairy.

[leebyron]

The leaf nodes on input types coerce input into the correct shape - does that help? Or you want to have the ability to have, for example, an input type which is an array of values, but provide it to server code as a comma-separated string?

[wmertens]

That latter example, exactly.

…

On Tue, Apr 25, 2017, 6:52 AM Lee Byron ***@***.***> wrote: The leaf nodes on input types coerce input into the correct shape - does that help? Or you want to have the ability to have, for example, an input type which is an array of values, but provide it to server code as a comma-separated string? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#747 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADWlhiEgexd_7oyNz8K9Cw_k7Ydu142ks5rzXvzgaJpZM4MW0Uq> .

[wmertens]

Another example is where your database expects a normalized structure but the graphql mutation interface is the joined structure. Without a per-type unresolve, you need to implement the normalization in every mutation call that includes the type somewhere.

Basically, resolve maps from server representation to graphql representation, and unresolve would do the reverse.

[wincent]

I get the use case, conceptually, but it's still not quite clear to me when/how these unresolve methods would be called.

[wmertens]

I would expect these unresolve()rs to be called before the args object is given to the mutation's resolve(root, args, context, info). That way, the server code works with an inbound server-domain object, just like it returns server-domain objects.

So suppose an inbound mutation has a ImageInput argument, an object like {id, title, alt, tags[]}, and on the server that is stored as {uploadId, meta: {title, alt, tags-as-csv}}, then the ImageInput type would have an e.g. unresolve(inputvalue) function that returns the converted value. Graphql would walk then input args schema, calling unresolvers depth-first.

[wmertens]

How about just supporting resolve on the fields of input objects? Conceptually simple, right?

const Foo = new GraphQLObjectType({
  name: 'Foo',
  fields: {
  	items: {
  		type: new GraphQLList(GraphQLString),
  		resolve: ({items}) => items.split(','),
  	},
  },
})

const FooInput = new GraphQLInputObjectType({
  name: 'FooInput',
  fields: {
  	items: {
  		type: new GraphQLList(GraphQLString),
  		resolve: (_, items) => items.join(','),
  	},
  },
})

The resolvers would get called right after the value is parsed, so depth-first.

Signature could be resolve(parsingObject, parsedField, context, info). Then the resolver can also mutate the given parsingObject, so that you can rename fields. If the resolver returns undefined, the value isn't added to the parsingObject.

const Foo = new GraphQLObjectType({
  name: 'Foo',
  fields: {
    niceName: {
      type: GraphQLString,
      resolve: ({badName}) => badName,
  	},
  },
})

const FooInput = new GraphQLInputObjectType({
  name: 'FooInput',
  fields: {
    niceName: {
      type: GraphQLString,
      resolve: (root, value) => {
        root.badName = value
      }
  	},
  },
})

[IvanGoncharov]

@wmertens I think this issue partly overlaps with #361 (comment)
I agree with @leebyron comment in #361 that input validation should be done before calling resolvers.

But for argument transformation, I think it should be done inside resolvers. The resolver should receive arguments that match field definition especially since it's documented in the specification: http://facebook.github.io/graphql/June2018/#sec-Value-Resolution

[wmertens]

@IvanGoncharov there is no overlap because that issue is about output types and there is even a workaround possible by decorating the schema.

However, input types have no transformation possibilities besides creating a scalar type per resolver, which would even cause the schema to change.

I also disagree that this is precluded by the spec, since the spec is purely about the schema and this is implementation-specific.

I really think that adding this simple feature will lead to less mutation resolver code with better reuse and thus higher quality.

[IvanGoncharov]

@wmertens If we allow changing types of arguments than resolvers will stop being type-safe. For example, you lose the ability to generate typings for your arguments, like this: https://github.com/nknapp/graphql-typewriter/blob/master/test/schemas/arguments.ts#L8

It also a problem for any GraphQL middleware that will try to wrap resolve functions since it can't expect that args value will match args definitions.

Scalars are the only place where graphql-js allow you to change types and I don't think we should add the second place especially since #1419 will provide good enough alternative.

[wmertens]

• not everybody uses typescript
• the type of the InputType will be whatever the resolver returns, or if there is no resolver, the same graphql type as before

Types are nice, but now you're using them as an argument against something that would improve code quality?

[wmertens]

Actually I'm not sure that we're on the same page. I am only requesting a nicer way to map graphql inputs to their server-side equivalents, just like output resolvers are a nice way to map server-side data to graphql.