Fork me on GitHub
#graphql
<
2022-09-28
>
enn19:09:36

Within a Lacinia resolver, what is the recommended way to determine the GQL types of its arguments? I’ve been playing with the selection API but am not having a lot of luck understanding how it is intended to be used.

jkxyz19:09:27

Surely the argument types are static because they're in the schema? Why would you need to determine them dynamically?

enn20:09:46

I have resolvers (and helpers that generate resolver fns) that are generic. They may be used in various different fields which may have different arguments of different types. My specific use case is that my input is a nested data structure, and I want to walk it (in such a generic resolver helper) and find all values of a given (GraphQL) type, at any level of the input. The workaround I’ve settled on is using a scalar transformer (because the type of interest happens to be a scalar type) to attach metadata to values of this type, then in the resolver I can walk the input looking for that metadata flag. But this feels roundabout.

jkxyz20:09:11

There may be some information in the context map about which resolver/field is currently being resolved, but I'm not sure. It seems like an anti-pattern, and I'd avoid using resolver fns for more than one resolver. Instead I'd wrap the common code in outer resolvers that knows the type info. If you can statically pass the argument type to your helper then you could look up its shape in the schema and dynamically find paths to all the fields with the type you're interested in. Or if it's a small number of top-level types then you could write a static function per type that gets what you want. Using the scalar transformer is a decent workaround but I'd say the kosher way is to rely on the schema and differentiate your code by having different resolver fns that know the types they're receiving.

enn21:09:06

Why do you think dispatch is an anti-pattern here?