Simplify input type definition

One of the things I’d like to consider before 1.0 is whether there’s a simpler way for us to express inputObjectType.

The only reason I originally designed the current API to match output, was to be able to capture TypeName / FieldName as generics to know the type for a potential defaultArg, which is actually a really rare use case, dead simple to remedy, and should be validated by graphql-js at runtime of the schema definition anyway.

The current API is a lot of ceremony for not nearly the amount of gain you get with typing on the output end with arg definition, the resolve fn params & return value, any typing on plugins like authorize, etc. Input fields don’t need any of that.

Further, it’s very common to re-use field across input types… being able to define a decent base “partial” of an input type, and be able to spread it across multiple input types is very useful, the way you can with args.

One idea, is a new leaner API inputType to live alongside the existing inputObjectType, with a new inputField if you want to decorate w/ description / deprecation / default:

inputType('InputTypeName', {
  someRequiredType: nonNull('SomeInputType'),
  someString: 'String',
  someInt: 'Int',
  requiredInt: nonNull('Int'),
  listWithDescription: inputField(list('Int'), { description:  "This has a description" }),
  someType: OtherInputType
})

compare that to:

inputObjectType({
  name: 'InputTypeName',
  definition(t) {
    t.field('someRequiredField', {
      type: 'SomeInputType'
    })
    t.string('someString')
    t.string('someInt')
    t.nonNull.string('requiredInt')
    t.list.int('listWithDescription', {
      description: "This has a description"
    })
    t.field(OtherInputType)
  }
})

I think the ability to define & merge fields across multiple input types is the really powerful point here. What would be even better though, is if we could make args & inputType members have a unified API, as they do in graphql-js.

Not 100% convinced on this / not really suggesting we remove the existing inputObjectType, but now that nullable / nonNull / list api has landed - this was a big thing I was imagining that API could be really useful for.

@jasonkuhrt / @Weakky WDYT?

[tgriesser]

I feel this simplified syntax could easily be a plugin.

Yeah that’s actually a very good point, I was on the fence about this to begin with. Agreed this could probably be a userland thing / show up in the docs as an example of what you could do.

intArg vs t.int()

Yeah, makes sense. The difference here is that t.int is a builder for the object’s fields, whereas intArg isn’t bound by use, the same arg def can be used in multiple positions.

In theory, we could add t.intArg but it’d just be sugar for the import (another thing that could be a plugin 😄

[jasonkuhrt]

Just hit a use-case for this while doing some design sketching for the new Nexus Prisma Plugin. The ability for generation of statically importable input type defs that can be overriding using spread syntax (or like-functions).

I find it odd that the config approach would be layered over the incremental API. That seems backwards to me. And indeed internally nexus just turns the result of that incremental API into config-like objects.