Add support of wildcard fields

[koistya]

One use case that comes to mind is form validation, for example:

GraphQL Query

mutation {
  createUser(email: "[email protected]", password: "Passw0rd") {
    state: {
      isValid,
      errors*                   <-- here
    },
    user {
      id,
      email,
      emailVerified
    }
  }
}

GraphQL Response

{
  data: {
    state: {
      isValid: false,
      errors: {
        '': [
          'Failed to create a new user account.'
        ],
        email: [
          'User with this email address ([email protected]) already exists.'
        ]
      },
    },
    user: null
  }
}

Ref #117, graphql/graphql-js#44

[dylanahsmith]

You can define your error type to have fieldName and message fields so that you don't need support for a wildcard. That would also allow your schema to evolve in case you want to attach more information to an error, like an error code.

👎 to having wildcards, since that also opens a huge can of worms about what is being returned, especially if the wildcard matches fields with arguments or object types with back-references, etc.

[dschafer]

You can define your error type to have fieldName and message fields so that you don't need support for a wildcard. That would also allow your schema to evolve in case you want to attach more information to an error, like an error code.

Yep, I like this approach a lot; that's what I would recommend doing.

#127 contains more discussion about wildcard and why we chose not to include them. Between using fragments and @dylanahsmith's approach to situations like the one you describe, we've found that they tend not to be needed.