Thanks. Guess this also points towards more tests starting with actual query strings
In GraphQL generally (and Lacinia specifically) is attaching a (default?) resolver to an object supported?
Line 7 above.
no; you can only add resolvers on field and queries (which are secretly fields of the query type)
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
(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)
I am wondering what your use case would be ^^. Not that I’m the expert here, but I am interested
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.
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.
makes sense. Thanks!
I've found, painfully, that excessive concision and magic is not, in the long run, better that explicit (if sometimes redundant) data.
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 🙂
indeed.