This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-16
Channels
- # announcements (8)
- # aws (28)
- # babashka (26)
- # beginners (125)
- # calva (18)
- # chlorine-clover (2)
- # cider (12)
- # cljs-dev (6)
- # cljsrn (4)
- # clojure (134)
- # clojure-europe (31)
- # clojure-italy (2)
- # clojure-nl (14)
- # clojure-uk (83)
- # clojurescript (81)
- # conjure (4)
- # cursive (2)
- # datomic (145)
- # emacs (13)
- # events (3)
- # figwheel-main (14)
- # fulcro (30)
- # graalvm (23)
- # graphql (15)
- # helix (21)
- # jackdaw (20)
- # juxt (1)
- # lambdaisland (4)
- # leiningen (2)
- # malli (12)
- # meander (22)
- # observability (22)
- # off-topic (27)
- # pedestal (3)
- # re-frame (12)
- # reitit (1)
- # releases (2)
- # rewrite-clj (3)
- # shadow-cljs (67)
- # spacemacs (7)
- # sql (1)
- # tools-deps (19)
- # unrepl (2)
- # xtdb (25)
Q: I want to use the data inside ::lacinia/selection in my resolvers. Is this considered a stable public api/data?
It is not. Use it are your peril. However, there's the selections API that exposes the most useful information in there.
I’m glad I asked 🙂. What I’m trying to see is the field “type” for non-leaf resolvers. I can infer if from the keyword namespaces in the data from the selections api but that seems a bit indirect. Is there a better way?
since I always have an “id” field in my queries, here’s what seems to work using the selection api
(some->> (executor/selections-tree context)
(select-first [MAP-KEYS #(= "id" (name %))])
namespace
keyword)
just wondering if there’s a more direct way to do this but I’m happy to move forward with this solution
The conflict here is that we really don't want to lock down the structure of the many internal keys in the context, as that handcuffs against any future changes and improvements.
So we've been gradually extending the preview API, which is something we can test and maintain, even in the face of a reorganization of the data in the context.
At this point, we can add more data to the maps returned by https://walmartlabs.github.io/apidocs/lacinia/com.walmartlabs.lacinia.executor.html#var-selections-seq2 without breaking any clients, so that's who I'd prefer to go.
Returning more field type data, as well as field and argument directives, would address a lot of needs, AFAIK.