validationErrors in info argument?

[alexstrat]

The extra argument validationErrors is visible in the produced schema while, apriori, the client does not need to know it exists.

Wouldn't be better injected in the info argument of resolver?

createUser(_, args, ctxt, info) {
  if(info.validationErrors && info.validationErrors.length) {
    // guess i should throw
  }
}

[barbieri]

hum... this is a good point, we could inject it in info indeed, is that more common than using args?

[cabelitos]

I like the idea, I think that this can also be done for the @hasPermission directive

[barbieri]

@alexstrat on your message, 2 remarks:

1. there is no need to check length, it should contain elements if it's an array, avoiding the need to check twice.
2. "guess I should throw" depends. If the elements are NON nullable, then it will throw and the resolver is not even called. The validationErrors will be filled if some nullable property failed and it was converted to null. Matches the output logic: if a resolver fails it will record in result.errors and the specific field is made null, respecting the "bubble" effect up to the first nullable object, if none is nullable (ie: arg is non-null), then it will not call the resolver.

The idea is that the resolver may use nullable objects and get a sanitized version, having the option to look at validationErrors to know if they are critical or not on its own -- ie: eventually use some default, etc.

[barbieri]

Will be done alongside #11 that introduce an optional policy argument.

[cabelitos]

fixed on 2.0.0 (available on NPM right now)