Validation errors for schema about howtographql HOT 4 CLOSED

Hi Radoslav - sorry about the delay!

I think it is really important that all server implementations in howtographql use the same schema so al frontend examples can be compatible.

For that reason I would be in favour of not modeling errors in the response data.

You mention that the graphql build-in errors are hard to handle on the client side. I would like to better understand why you think so. This is how we handle all errors for our main app, console.graph.cool and this is also how we tell our customers to handle errors (https://www.graph.cool/docs/reference/simple-api/error-management-aecou7haj9/)

I am aware that Apollo currently has very poor support for graphql build-in errors. I'm hoping we can help them fix that asap: apollographql/apollo-client#51 (comment)

ps, I have a good friend who used to work on nativescript at Telerik before moving to Copenhagen. Maybe you know him?

from howtographql.

Hi @sorenbs

All implementation should definitely be the same. I'll do what everybody agrees.

My personal preferences is to have validation errors in errors field and not use the schema. I had quite good success with that approach.

For one having multiple validation errors returns as schema errors is badly supported by Apollo, Elixir's Absine and Ruby gem. (Ruby gem advices agains them)

Which would lead to problems if we want to handle the following situation:

createLink ->
   - too short description
   - invalid url

On the other side having errors with Error type gives you:

• more control about the response
• easier to handle in frontend (in forms especially)
• you have clear separation between errors caused by a user and system errors.

The way I handle almost all of my forms is something like:

// `submit` is apollo mutation, `params` is data from form
const { data: { errors, node  } } = await this.props.submit(params);

// if there are errors, then just add errors to form state
// ...and you are done
if (errors.length> 0) {
  this.setState({ isSubmitting: false, errors });
} else {
  // on success just pass the node
  this.setState({ isSubmitting: true });
  this.props.onSuccess(node);
}

I'm actually not very sure how to handle this, with schema errors. I suspect something with try/catch.

But again, what ever is decided, I would go with it.

p.s. I know couple of people from Telerik NativeScript from Sofia. What is your friend's name?

from howtographql.

Thanks - let's keep the original schema then.

The error handling pattern you showed is very compelling. Apollo is currently reimplementing their error handling logic (linked above). If you have the time, it would be really nice if you could present this pattern to them and start a conversation about how to enable the same convenience when using schema errors.

It's a small world :-) My friend is Yavor Georgiev.

from howtographql.

👍 I'll work with the current schema

from howtographql.