You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a field arg is typed in the DSL as optional, a request that passes an explicit null, is considered valid. This means graphql-js will pass through a user's explicit null. This, in turn, means that if Grats is going to generate an optional argument, the user's field resolver must be capable of accepting null.
Today it's possible to define a function which is not expecting in its typescript types, but could get passed a null at runtime:
/** @gqlType */exportdefaultclassQuery{/** @gqlField */someField(args: {greeting: string|undefined}): string{if(args.greeting===undefined){return"Hello!"}returnargs.greeting;// OOPS! Might return `null` here, which is not a `string`.}}
In theory when we do applyServerDirectves (or in some similar place) we could wrap the resolver functions to match what the user-defined code expects, but I think that's probably not the right direction to head.
If a field arg is typed in the DSL as optional, a request that passes an explicit null, is considered valid. This means
graphql-js
will pass through a user's explicit null. This, in turn, means that if Grats is going to generate an optional argument, the user's field resolver must be capable of acceptingnull
.Today it's possible to define a function which is not expecting in its typescript types, but could get passed a null at runtime:
Playground
I think the best solution here is for Grats to error in this case and force you to add
| null
to the argument's type.The text was updated successfully, but these errors were encountered: