graphql

shen 2020-06-03T06:53:32.132Z

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

mafcocinco 2020-06-03T15:12:56.134300Z

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

mafcocinco 2020-06-03T15:13:10.134700Z

Line 7 above.

2020-06-03T16:36:17.134900Z

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

2020-06-03T16:37:59.135100Z

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

2020-06-03T16:41:49.135300Z

(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)

2020-06-03T16:44:11.135500Z

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

mafcocinco 2020-06-03T17:34:41.136800Z

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.

hlship 2020-06-03T17:34:46.137Z

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.

mafcocinco 2020-06-03T17:35:08.137200Z

mafcocinco 2020-06-03T17:35:35.137600Z

makes sense. Thanks!

hlship 2020-06-03T17:36:42.137800Z

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

2020-06-03T17:41:32.138Z

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 🙂

mafcocinco 2020-06-03T17:44:13.138200Z

indeed.