Validations that cannot be ran on the client side and the errors object about graphql-spec HOT 6 CLOSED

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).

from graphql-spec.

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?

from graphql-spec.

+1

from graphql-spec.

+1

from graphql-spec.

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

@leebyron

from graphql-spec.

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

from graphql-spec.