This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-07
Channels
- # 100-days-of-code (13)
- # beginners (12)
- # business (6)
- # cider (6)
- # cljdoc (9)
- # cljs-dev (1)
- # cljsrn (4)
- # clojars (4)
- # clojure (31)
- # clojure-dev (12)
- # clojure-uk (11)
- # clojurescript (16)
- # cursive (1)
- # datascript (4)
- # datomic (10)
- # editors (1)
- # figwheel-main (3)
- # graphql (10)
- # lein-figwheel (29)
- # off-topic (1)
- # pedestal (1)
- # re-frame (31)
- # reitit (3)
- # shadow-cljs (27)
- # slack-help (5)
- # spacemacs (1)
- # yada (5)
i'm unclear on a very basic concept: will Lacinia auto resolve nested queries, e.g.:
history {
id
body
user { id name }
}
or would this require that my history-resolver
manually invoke the user-resolver
?the history-resolver
knows the user-id
but i don't know how it would pass it to user-resolver
unless there is some convention i'm missing
kinda weird because that means i'd need two resolver functions: one that takes :id
out of the args
i.e. get-user-by-id
and another that takes :id
out of the value
(3rd arg) depending on whether it was a top level query or part of nested resolution. :thinking_face:
In general, Lacinia doesn't know anything about where your data is stored or how to get it. That's entirely the domain of your resolvers.
There's a trivial but useful case: where the field name matches a key of a resolved value (a map or record), in which case, Lacinia supplies a default resolver function automatically.
The id
arg and the id
field are quite different. In one case, it is passed into your resolver function, so that data can be obtained from an external store. In the other, Lacinia is supplying a default resolver for you, to extra a selected field from a resolved value (the very resolved value that your earlier resolver function provided).
Often it is convienient to resolve values in one "shape" (defined by your storage) and have additional nested resolvers to re-shape the data as needed. For example, we expose data that is partly stored in our database, partly obtained from an internal 3rd party. So if you are using some of that 3rd party data, the top-level resolvers will fetch it in a block (to avoid N+1 external calls) but then other resolvers will fold that raw data into the shape defined by the GraphQL schema (the 3rd party is incomprehensibly verbose).