This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-11
Channels
- # announcements (4)
- # aws (6)
- # babashka (40)
- # beginners (318)
- # biff (4)
- # bootstrapped-cljs (9)
- # calva (19)
- # chlorine-clover (1)
- # cider (3)
- # clj-on-windows (25)
- # cljdoc (8)
- # cljfx (1)
- # cljs-dev (30)
- # cljss (2)
- # clojure (62)
- # clojure-chile (9)
- # clojure-europe (11)
- # clojure-finland (17)
- # clojure-italy (1)
- # clojure-kc (1)
- # clojure-nl (3)
- # clojure-spec (27)
- # clojure-uk (40)
- # clojuremn (1)
- # clojurescript (51)
- # conjure (6)
- # cursive (8)
- # data-science (9)
- # datahike (4)
- # datascript (1)
- # datomic (31)
- # emacs (10)
- # emotion-cljs (1)
- # events (1)
- # figwheel-main (16)
- # find-my-lib (1)
- # fulcro (30)
- # graalvm (3)
- # graphql (12)
- # helix (16)
- # honeysql (5)
- # jobs (1)
- # jobs-discuss (10)
- # juxt (3)
- # kaocha (26)
- # lambdaisland (3)
- # leiningen (15)
- # malli (7)
- # off-topic (100)
- # pathom (8)
- # pedestal (15)
- # protojure (24)
- # re-frame (2)
- # reagent (7)
- # reitit (22)
- # remote-jobs (1)
- # shadow-cljs (140)
- # spacemacs (17)
- # spire (2)
- # tools-deps (23)
- # uix (11)
- # vim (5)
- # xtdb (3)
- # yada (3)
Posted by accident to #pedestal — does anybody else have trouble with lacinia-pedestal 0.13.0 and :ide-connection-params
?
(->>
(lacinia/graphiql-ide-response {:ide-path "/_graphiql"
:ide-connection-params {:some "thing"}})
:body
(clojure.string/split-lines)
(filter (fn [s] (re-find #"connectionParams" s))))
Turns out it was a problem on my end — AOT compiled deps meant I had .class files from 0.12 that had a newer timestamp than the 0.13 jar.
Do you find that AOT compilation helps server startup enough to offset the problems it often causes?
Hi, does lacinia support qualified keyword fields? The spec only accepts simple-keywords. If I want to return my maps I need to transforms them to simple keywords.
e.g. I have {:person/id 123 :person/name "foo"}
. But before I return that, I have to transform it into {:id 123 :name "foo"}
. Is there a easy way to handle this? It would be great if I could actually return qualified keywords to the frontend, but that's probably a limitation of graphql
Well; in the schema, how would that look?
I’m pretty sure that GraphQLs schema definition requires fields to be ‘the usual’ identifier shape (e.g. doesnt start with a number, and then lettters, numbers and underscores), so colons are probably out of the question 🙂