Allow setting of makeResolverTypeCallable
matthewlilley opened this issue · comments
I'm re-writing our graph-client package at the moment and run into an issue when modularising, and especially reusing resolvers.
This expression is not callable.
Not all constituents of type 'Resolver<ResolverTypeWrapper[], {}, FarmTypes.Context & MasterChefV2Types.Context & BlocksTypes.Context & MasterChefV1Types.Context & XSushiTypes.Context & ... 6 more ... & { ...; }, RequireFields<...>>' are callable.
I then found this comment from @dotansimha on an old issue.
dotansimha/graphql-code-generator#6310 (comment)
It sounds like I want this to be enabled?
I notice that selections aren't made if calling the resolver directly.
Should I avoid calling resolvers in other resolvers?
Should SDK be used in these cases instead?
You should avoid calling resolvers directly, and SDK needs to be used.
@ardatan Thanks for clarification.
Also resolvers are not always functions, they can be an object like
{
selectionSet: ...,
resolve: (root, args, context, info) => {}
}
@ardatan gotcha, have been digging into graphql, mesh & graphclient a lot over the past week. Hopefully will be able to contribute back a bit more now I'm understanding a bit more, I notice the graphclient is mostly a thin wrapper.
@ardatan I am using sdk within some resolvers now, instead of call resolvers from resolvers. However, I'm struggling with type errors, the SDK return type doesn't seem to be compatible with the resolver return type without casting to it.
What's the best practice here? I'm always a bit hessitant about casting.
Oh in resolvers, incontext sdkcontext.SOURCE_NAME.Query.FIELD_NAME should be used not the other sdk :)
Other SDK is for clients not stitching.
Oh in resolvers, incontext sdk
context.SOURCE_NAME.Query.FIELD_NAMEshould be used not the other sdk :) Other SDK is for clients not stitching.
Ah, so this is exactly what I was doing before. The issue then was that selections weren't made in a lot of cases.
@ardatan I have situations where I want to reuse resolver logic in other resolvers, or even multiple times within the same resolver.
Writing small wrappers is a better pattern here?
Friendly bump on above message @ardatan. It's not clear how to deal with complex cases like this.
I guess I should ask a few questions which would help.
Are there cases where it's acceptable to use the SDK within a resolver?
If not, and we want to reuse logic which is used in custom resolvers, what is the best practice for this?
An example of such as case can be seen here:
https://github.com/sushiswap/sushiswap/blob/refactor/graph-client/packages/graph-client-2/resolvers/pairs/index.ts#L62
Here we cannot use "context.SOURCE_NAME.Query.FIELD_NAME" since the query is an extension and isn't available here, the query might be shared by multiple contexts too.