Allow Grats to validate context values about grats HOT 6 CLOSED

Another option is to simply enforce that the context argument (if present) on all resolvers have to reference the exact same type. I doesn't matter what type it is (Request/string/{}/etc) but they all have to be the same.

So this would be valid:

function resolverOne(_: Foo, args: {}, context: MyContextType) {}
function resolverTwo(_: Bar, args: {}, context: MyContextType) {}

but this would make Grats emit an error:

function resolverOne(_: Foo, args: {}, context: MyContextType) {}
function resolverTwo(_: Bar, args: {}, context: string) {}

because MyContextType is not string.

Similarly, this would be fine:

function resolverOne(_: Foo, args: {}, context: string) {}
function resolverTwo(_: Bar, args: {}, context: string) {}

This as well:

function resolverOne(_: Foo, args: {}, context: MyContextType) {}
function resolverTwo(_: Bar, args: {}) {} // this doesn't use the `context` arg

And maybe, this could be allowed as well

function resolverOne(_: Foo, args: {}, context: MyContextType) {}
function resolverTwo(_: Bar, args: {}, context: unknown) {}

Typing it as unknown would be a safe-ish escape hatch, if one can't really refer to a concrete type there, forcing the resolver implementation to unsafely cast context to something else, or dynamically inspect the value with instanceof or type guards etc.

IMO this is an elegant way for Grats to enforce the type of context, doesn't require a config or docblock tags, etc.

It still on the developer to ensure the type of the context passed to the executor is the same the resolvers expect, I doubt Grats can help with that...

from grats.

from grats.

A related topic to context variable typing is the ability to support positional arguments. I've written an issue for that in #23. In short, if Grats can explicitly know which arg is typed as the context value (for example via a /** @gqlContext */ tag), it could allow you to define your arguments as positional arguments. See the #23 for more context.

from grats.

I've tried out the @gqlContext approach (without positional arguments) here: #24

from grats.

Kinda torn on positional arguments... I can see how it might be more ergonomic for others; OTOH, since GraphQL field arguments are keyword arguments, IMO it's nice that the args mirrors that. Also, keeping the resolvers' signature as close as possible to what graphql-js expects allows for easy migration to Grats, which is good for adoption.

Or maybe it's just that the args: {/* ... */} syntax is most familiar to me, and my brain is just resisting change 😅

from grats.

I may pick a slightly more opinionated restriction: the ctx argument must be typed using a type that resolves to the same definition. That saves us from having to actually perform type checking (which is not fully supported by the TS library)

Btw I agree, it has to (nominally) resolve to the same type, so for example:

function resolverOne(_: Foo, args: {}, context: { foo: string; bar: number }) {}
function resolverTwo(_: Bar, args: {}, context: { foo: string; bar: number }) {}

It's my understanding that for TS, those two context args don't have the same type, but rather two independent types that happen to be 100% compatible between them. Proper type checking is needed to ensure that the types actually are compatible. Also, in practice, devs will name the type and then refer to that by name (possibly with the @gqlContext added as well) so IMO it's Ok to reject these cases and provide actions ("put the type under a name and use the name instead") as part of the error message.

from grats.