Fork me on GitHub
#graphql
<
2020-06-11
>
orestis13:06:08

Posted by accident to #pedestal — does anybody else have trouble with lacinia-pedestal 0.13.0 and :ide-connection-params ?

orestis13:06:52

(->>
   (lacinia/graphiql-ide-response {:ide-path "/_graphiql"
                                   :ide-connection-params {:some "thing"}})
   :body
   (clojure.string/split-lines)
   (filter (fn [s] (re-find #"connectionParams" s))))

orestis13:06:10

returns (" connectionParams: --NO-MATCH--")

orestis14:06:18

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.

orestis14:06:35

So I was using the 0.13 graphiql.html file but the 0.12 interpolation 🙂

hlship16:06:48

Ouch! The merits of lein clean ...

hlship16:06:14

Do you find that AOT compilation helps server startup enough to offset the problems it often causes?

hlship16:06:33

We deploy as Uberjars but w/o AOT.

Kevin19:06:47

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

Lennart Buit21:06:40

Well; in the schema, how would that look?

Lennart Buit21:06:59

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 🙂