Validations that cannot be ran on the client side and the errors object

[D1plo1d]

Let's say you have a uniqueness constraint on a field in a mutation. For example the email field must not match any existing email in the database.

In graphql/graphql-js#179 it's been suggested that we shouldn't use the server to validate our forms. But in the case of our uniqueness constraint the server is the only place with enough information to determine if our form is valid.

The format of the errors response appears to be aimed at debugging. Specifically a line number is given as the only context for the error. Presumably this is so that a programmer can then use that line number to find the issue in their query/mutation. So to me the current errors array looks more analogous to a stack trace then an error object like we'd traditionally expect in a RESTful API (eg. {"errors": {"email": ["this email has been taken"]}}).

The advantage of the error object is that we can easily match the keys in the error to the names of the fields in our form to add an error message for our users next to the offending field.

I propose that changing the errors array to an errors object would give developers access to field names and error messages in a format that is easy to map on to their forms and display to users. Eg:

{
  "errors": {
    "email": {
      "messages": ["The email address zuckerberg@facebook.com has already been taken"],
      "locations": []
    }
  }
}

Relevant Spec Section: https://facebook.github.io/graphql/#sec-Errors

[satahippy]

+1

[sulliwane]

+1

[CatTail]

I was wondering how facebook handle error and display related error information for user with graphql?

@leebyron

[leebyron]

The data in the errors object is definitely typical for debugging. But of course the existence of an error could be used to render something in a UI about data not being available.

My suggestion for the example you bring up here is to allow for data for a user-facing report in the payload of your mutation. It's often the case that mutation payloads include a "didSucceed" field and a "userError" field. If your UI requires rich information about potential errors, then you should include this information in your payload as well. For example, maybe you want to highlight the email field red, you might include something like a boolean "wasBadEmail".

The general philosophy at play is that Errors are considered exceptional. Your user data should never be represented as an Error. If your users can do something that needs to provide negative guidance, then you should represent that kind of information in GraphQL as Data not as an Error. Errors should always represent either developer errors or exceptional circumstances (e.g. the database was offline).

[D1plo1d]

Thanks @leebyron. didSucceed and userError should work for my usage.

It might be useful to spec out userErrors somewhere similar to how Relay specifies connections and edges without necessarily including them in the GraphQL language spec. I feel like user input error handling is as common a concern as pagination in my code. Would it make any sense to consider this for a future version of Relay?

[koistya]

Input validation and user-friendly error messages in GraphQL mutations on Medium.com