Fork me on GitHub
#graphql
<
2020-06-03
>
shen06:06:32

Thanks. Guess this also points towards more tests starting with actual query strings

mafcocinco15:06:56

In GraphQL generally (and Lacinia specifically) is attaching a (default?) resolver to an object supported?

Lennart Buit16:06:17

no; you can only add resolvers on field and queries (which are secretly fields of the query type)

Lennart Buit16:06:59

that said, you can also not just get an object from a graphql endpoint, so there must be a query that gives you this :my-object right, which you can add a resolver to

Lennart Buit16:06:49

(At my company we do have something like you are suggesting specifically for Relay’s node and nodes query, but that also generates a custom query with custom resolver)

Lennart Buit16:06:11

I am wondering what your use case would be ^^. Not that I’m the expert here, but I am interested

mafcocinco17:06:41

Mostly I was hoping to be able to supply a default resolver on the object so that when it was nested within another object, we would not have to specify the resolver for that field type every time.

hlship17:06:46

In the general spirit of Clojure, you can put a :resolve key on any part of the schema, but Lacinia will only recognize it where it belongs (inside a field description). There's a pretty detail spec for that.

mafcocinco17:06:35

makes sense. Thanks!

hlship17:06:42

I've found, painfully, that excessive concision and magic is not, in the long run, better that explicit (if sometimes redundant) data.

Lennart Buit17:06:32

Yeah, and its not that much repetition anyway right, you can have the same resolver for two fields of different objects, its just the resolve key in your schema that is duplicated 🙂

mafcocinco15:06:10

Line 7 above.