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
#5216 improved the GraphQL codegen resolver types (and is a good change!), but it seems to create some problems with calling resolver functions from tests in TypeScript (including in generated service tests).
To reproduce a simple case:
yarn create redwood-app redwood-resolvers-not-callable --typescript
cd redwood-resolvers-not-callable
yarn rw upgrade --tag rc
yarn rw g sdl UserExample
yarn rw type-check
Several errors will appear, such as:
src/services/userExamples/userExamples.test.ts:18:26 - error TS2349: This expression is not callable.
Not all constituents of type 'Resolver<ResolverTypeWrapper<UserExample>[], {}, RedwoodGraphQLContext, {}>' are callable.
Type 'ResolverWithResolve<ResolverTypeWrapper<UserExample>[], {}, RedwoodGraphQLContext, {}>' has no call signatures.
18 const result = await userExamples()
~~~~~~~~~~~~
With that said, the above change will reveal further type errors, as the resolver typings require 2 arguments, e.g.:
src/services/userExamples/userExamples.test.ts:18:26 - error TS2554: Expected 2 arguments, but got 0.
18 const result = await userExamples()
~~~~~~~~~~~~~~
types/graphql.d.ts:10:7
10 args: TArgs,
~~~~~~~~~~~
An argument for 'args' was not provided.
src/services/userExamples/userExamples.test.ts:26:28 - error TS2554: Expected 2 arguments, but got 1.
26 const result = await userExample({ id: scenario.userExample.one.id })
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
types/graphql.d.ts:11:7
11 obj: { root: TParent; context: TContext; info: GraphQLResolveInfo }
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An argument for 'obj' was not provided.
It would be good to both improve the generated tests so they type-check and to demonstrate proper arguments for the new typings. It’s simple enough to add {} for args where necessary, but I think it’s non-obvious what should be passed as the second (obj) argument.
Possible solutions here might involve some sort of test helper(s) to either
wrap calls to the resolvers with more lenient arguments, or
help build valid arguments for the second (obj) parameter
Addendum: strict null checks
I will note that with strictNullChecks disabled, one can simply pass null or undefined as the second argument (or for any of root, context, or info). However, with strict: true (or even just strictNullChecks: true) in tsconfig.json, things get a bit more complicated with errors like:
Type of 'await' operand must either be a valid promise or must not contain a callable 'then' member. ts(1320)
and
Cannot invoke an object which is possibly 'undefined'. ts(2722)
I haven't quite figured out why the 'await' operand error occurs, but I have been able to work around it by overriding customResolverFn to return Promise<TResult> | TResult instead of Promise<Partial<TResult>> | Partial<TResult> -- though there may be drawbacks to this, so I'm not necessarily proposing it as a solution.
For the second error I've been using a helper that accepts a Partial of the second (obj) argument and basically
throws on an undefined resolver function
otherwise proceeds to call the function by casting the Partial obj argument to the correct non-Partial type (basically a hack).
The text was updated successfully, but these errors were encountered:
dac09
changed the title
(1.3.0-rc.0) Generated resolver type is not callable (and related issues)
(1.3.0) Generated resolver type is not callable (and related issues)
May 4, 2022
Cool, this all makes sense - makeResolverTypeCallable seems like a solid win.
I wonder if Redwood should provide a function for in testing that's like a resolverContextFake which can be arbitrarily passed in during tests (inside prod code you'd be fine to pass along your current context)
Note that this pertains to 1.3.0-rc.0.
#5216 improved the GraphQL codegen resolver types (and is a good change!), but it seems to create some problems with calling resolver functions from tests in TypeScript (including in generated service tests).
To reproduce a simple case:
yarn create redwood-app redwood-resolvers-not-callable --typescript cd redwood-resolvers-not-callable yarn rw upgrade --tag rc yarn rw g sdl UserExample yarn rw type-check
Several errors will appear, such as:
A direct solution to this error could be to include
makeResolverTypeCallable: true
(part of https://www.graphql-code-generator.com/plugins/typescript-resolvers) in the defaultgraphql-code-generator
config.With that said, the above change will reveal further type errors, as the resolver typings require 2 arguments, e.g.:
It would be good to both improve the generated tests so they type-check and to demonstrate proper arguments for the new typings. It’s simple enough to add
{}
forargs
where necessary, but I think it’s non-obvious what should be passed as the second (obj
) argument.Possible solutions here might involve some sort of test helper(s) to either
obj
) parameterAddendum: strict null checks
I will note that with
strictNullChecks
disabled, one can simply passnull
orundefined
as the second argument (or for any ofroot
,context
, orinfo
). However, withstrict: true
(or even juststrictNullChecks: true
) in tsconfig.json, things get a bit more complicated with errors like:and
I haven't quite figured out why the
'await' operand
error occurs, but I have been able to work around it by overridingcustomResolverFn
to returnPromise<TResult> | TResult
instead ofPromise<Partial<TResult>> | Partial<TResult>
-- though there may be drawbacks to this, so I'm not necessarily proposing it as a solution.For the second error I've been using a helper that accepts a
Partial
of the second (obj
) argument and basicallyundefined
resolver functionobj
argument to the correct non-Partial type (basically a hack).The text was updated successfully, but these errors were encountered: