Example

Consider the following document string that contains excessive ingored tokens.

Example № 3{
  add(numbers: [1, -2]) {
    __typename
    ... on Success {
      result
    }
    ... on Error {
      message
      code
    }
  }
}

The string correctly representing the normalized GraphQL document looks like this.

Example № 4{add(numbers:[1 -2]){__typename ...on Success{result}...on Error{message code}}}

There are two space tokens in this string which are not strictly necessary to preserve the ability of the string to be parsed as GraphQL document:

• The space between 1 and -2 in the integer array
• The space between __typename and the tripple-dot punctuator ...

In other words, the following string contains the actually minimal amount of ignored tokens and would parse to the same GraphQL document like the one above.

Counter Example № 5{add(numbers:[1-2]){__typename...on Success{result}...on Error{message code}}}

The second string suffers significantly in terms of legibility. For a human, the token 1-2 might not be understood as two separate integers. Similarly, having the tripple-dot punctuator join two Name tokens might be considered ambiguous or might be perceived as a single Name token.

Example

Counter Example № 6{
  user(id: 4) {
    name: name
  }
}

Example № 7{
  user(id: 4) {
    name
  }
}

Example

Counter Example № 8{
  user(id: 4) {
    name
    friends {
      name
    }
    name
    friends {
      birthday
      name @uppercase
    }
    nameWithAlias: name
  }
}

Example № 9{
  user(id: 4) {
    name
    friends {
      name
      birthday
      name @uppercase
    }
    nameWithAlias: name
  }
}

Example

Counter Example № 10{
  user(id: 4) {
    ...UserData
  }
}

fragment UserData on User {
  name
}

Example № 11{
  user(id: 4) {
    name
  }
}

Example

This example assumes that that the return type of the user field is User.

Counter Example № 12{
  user(id: 4) {
    ... on User {
      name
    }
  }
}

Example № 13{
  user(id: 4) {
    name
  }
}

Example

Counter Example № 14{
  user(id: 4) {
    ... {
      name
    }
  }
}

Example № 15{
  user(id: 4) {
    name
  }
}

Example

Counter Example № 16{
  profile(id: 4) {
    handle
    ... on User {
      handle
      name
    }
  }
}

Example № 17{
  profile(id: 4) {
    handle
    ... on User {
      name
    }
  }
}

Example

Counter Example № 18{
  profile(id: 4) {
    ... on User {
      handle
      friends {
        name
      }
    }
    handle
  }
}

Example № 19{
  profile(id: 4) {
    handle
    ... on User {
      friends {
        name
      }
    }
  }
}

Example

Counter Example № 20{
  profile(id: 4) {
    ... on User {
      friends {
        name
      }
      __typename
      handle
    }
    __typename
    handle
  }
}

Example № 21{
  profile(id: 4) {
    ... on User {
      friends {
        name
      }
    }
    __typename
    handle
  }
}

Example

For this example, assume that the field profile returns an interface type Profile, and that there exist exactly two object types User and Organization that implement this interface type. Furthermore, assume that the Profile interface defines a field named handle.

Counter Example № 22{
  profile(id: 4) {
    ... on Organization {
      handle
      members {
        name
      }
    }
    ... on User {
      handle
      name
    }
  }
}

Example № 23{
  profile(id: 4) {
    handle
    ... on Organization {
      members {
        name
      }
    }
    ... on User {
      name
    }
  }
}

Example

Counter Example № 24{
  user(id: 4) {
    name
    ... @skip(if: true) {
      birthday
    }
    ... @skip(if: false) {
      friends {
        name
      }
    }
  }
}

Example № 25{
  user(id: 4) {
    name
    friends {
      name
    }
  }
}

Example

Counter Example № 26{
  user(id: 4) {
    name
    ... @include(if: true) {
      birthday
    }
    ... @include(if: false) {
      friends {
        name
      }
    }
  }
}

Example № 27{
  user(id: 4) {
    name
    birthday
  }
}

Example

Counter Example № 28query User {
  user(id: 4) {
    name
  }
}

query Profile {
  profile(userId: 4) {
    handle
  }
}

{
  user(id: 5) {
    birthday
  }
}

Example № 29{
  user(id: 5) {
    birthday
  }
}

query Profile {
  profile(userId: 4) {
    handle
  }
}

query User {
  user(id: 4) {
    name
  }
}

Example

Counter Example № 30query ($id: Int, $friendName: String) {
  user(id: $id) {
    friend(name: $friendName) {
      birthday
    }
  }
}

Example № 31query ($friendName: String, $id: Int) {
  user(id: $id) {
    friend(name: $friendName) {
      birthday
    }
  }
}

Example

Counter Example № 32{
  user(name: "Bill", birthday: "1955-10-28") {
    name
  }
}

Example № 33{
  user(birthday: "1955-10-28", name: "Bill") {
    name
  }
}

Example

Counter Example № 34{
  user(input: { name: "Bill", birthday: "1955-10-28" }) {
    name
  }
}

Example № 35{
  user(input: { birthday: "1955-10-28", name: "Bill" }) {
    name
  }
}

Example for Interface Types

For this example, assume that the field profile returns an interface type Profile, and that there exist two object types User and Organization that implement this interface type.

Counter Example № 36{
  profile(id: 4) {
    handle
    ... on User {
      name
    }
    ... on Organization {
      members {
        name
      }
    }
  }
}

Example № 37{
  profile(id: 4) {
    handle
    ... on Organization {
      members {
        name
      }
    }
    ... on User {
      name
    }
  }
}

Example for Union Types

For this example, assume that the field userResult returns a union type with two member types User and Error.

Counter Example № 38{
  userResult(id: 4) {
    ... on User {
      name
    }
    ... on Error {
      message
    }
  }
}

Example № 39{
  userResult(id: 4) {
    ... on Error {
      message
    }
    ... on User {
      name
    }
  }
}

Example for Nested Interface Types

For this example, assume the following GraphQL schema.

type Query {
  node(id: ID): Node
}

interface Node {
  id: ID
}

interface InterfaceA implements Node {
  id: ID
  fieldA: String
}

interface InterfaceB implements Node {
  id: ID
  fieldB: String
}

type ObjectA implements Node & InterfaceA {
  id: ID
  fieldA: String
}

type ObjectB implements Node & InterfaceB {
  id: ID
  fieldB: String
}

type ObjectAB implements Node & InterfaceA & InterfaceB {
  id: ID
  fieldA: String
  fieldB: String
}

Then the following query is normalized.

Example № 40{
  node(id: 4) {
    ... on InterfaceB {
      fieldB
    }
    ... on InterfaceA {
      fieldA
    }
  }
}

The two inline fragments cannot be reordered without potentially changing the order of fields in the execution result. If the returned node if of type ObjectAB then both type conditions of the two inline fragments will match, and the fields are returned in the order in which the inline fragments are included in the selection set.