Graphql-js: Examples on how/when to use GraphQLInputObjectType

[rodryquintero]

There is very little documentation on how/when to use GraphQLInputObjectType in mutation queries. I am beggining to use Graphql and the documentation is not very clear on this subject.

PD: I still don't understand it :)

[robzhu]

There are two helpful sections in the specification:
https://facebook.github.io/graphql/#sec-Input-Values
https://facebook.github.io/graphql/#sec-Input-Types

Here's an article with some good examples of Input Types and Mutations:
https://medium.com/@HurricaneJames/graphql-mutations-fb3ad5ae73c4

Please take a look and let me know if you have any additional questions afterward.

[rodryquintero]

I have read the @hurricanejames article and it has helped me understand mutations a little better. But I still think there should be a place for this topic in the libraries official documentation. Also, more examples of other use cases for InputTypes and InputValues would also be helpfull.

In my paritcular case, I have implemented successfully a mutation query on a personal project, so I don't really understand when I need to use an InputTypeobject in queries.

[robzhu]

I agree, we should have better docs that cover cases like these.

I don't really understand when I need to use an InputTypeobject in queries

Defining an InputObjectType provides more structure, especially if the inputs are naturally hierarchical.

[leebyron]

Agreed about needing better documentation - that's something we'll be working on more this year.

GraphQL's type system is represented by Input Types and Output Types to respectively handle inputs sent from a client during a query and the output response to that query.

Input types are useful for queries and mutations, often both include some input. When you write { user(id: 4) { name } }, the value 4 represented an input typed with the Input Type ID. Similarly, when you write a mutation, also you're supplying inputs.

Some types are permitted as both Input and Output types, like ID, String, or Boolean, but others are limited to each. Object types are Output types, they describe the types of the thing you're asking about when you write a query like { fieldA, fieldB, fieldC } - you can think of them sort of like Classes in other environments. They represent a value and you can call getter functions on them (fields, in GraphQL parlance). InputObject types are Input types that represent a collection of named values - you can think of them sort of like Structs or Records in other environments. They represent a provided value that has certain properties.

For an example of a query that uses an InputObject, consider an API for a bank's location service that found ATMs near you. You might need to tell it where you are:

{
  nearbyATMs(location: { lat: 48.8566, lon: 2.3522 }) {
    ...InterestingThingsAboutAnATM
  }
}

That location needs to be well typed so GraphQL knows what to expect and allow, it might use an input type:

input Location {
  lat: Float
  lon: Float
}

[rodryquintero]

Thanks @leebyron and @robzhu. This explains these concepts better than the info I found on the web.

[richburdon]

Hi @leebyron I understand the examples, but this doesn't really explain WHY different type systems are needed form input and output definitions :).

E.g., Say I have mutations that require a location (input Location {lat:Float, lng:Float}) AND a type that requires the same data. I have to create two different types. So pretty soon, we have dozens of pairs of types for all of these low-level types (Location, Address, FilterPredicate, etc.)

The only explanation I've seen (and I can't find this now) is that input types must be guarded to avoid recursion (so that they are serializable). But this wouldn't preclude them from being used by regular types -- and this would remove the redundancy above?

Thanks.

[sanjeevchopra]

Hi @leebyron I understand the examples, but this doesn't really explain WHY different type systems are needed form input and output definitions :).

E.g., Say I have mutations that require a location (input Location {lat:Float, lng:Float}) AND a type that requires the same data. I have to create two different types. So pretty soon, we have dozens of pairs of types for all of these low-level types (Location, Address, FilterPredicate, etc.)

The only explanation I've seen (and I can't find this now) is that input types must be guarded to avoid recursion (so that they are serializable). But this wouldn't preclude them from being used by regular types -- and this would remove the redundancy above?

Thanks.

I'd appreciate if someone can answer this question from @richburdon

[yaacovCR]

See a bit more discussion in #599