captbaritone / grats

Implementation-First GraphQL for TypeScript
https://grats.capt.dev
MIT License
306 stars 16 forks source link

Force optional args to accept null #18

Open captbaritone opened 11 months ago

captbaritone commented 11 months ago

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 */
export default class Query {
  /** @gqlField */
  someField(args: {greeting: string | undefined}): string {
    if(args.greeting === undefined) {
      return "Hello!"
    }
    return args.greeting; // OOPS! Might return `null` here, which is not a `string`.
  }
}
type Query {
  someField(greeting: String): String
}

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.

mandx commented 11 months ago

IMO it's the only type-safe solution, since Grats can't/won't alter how graphql-js handles this case?

captbaritone commented 11 months ago

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.