Posted by accident to #pedestal — does anybody else have trouble with lacinia-pedestal 0.13.0 and :ide-connection-params
?
https://clojurians.slack.com/archives/C0K65B20P/p1591877510185700
(->>
(lacinia/graphiql-ide-response {:ide-path "/_graphiql"
:ide-connection-params {:some "thing"}})
:body
(clojure.string/split-lines)
(filter (fn [s] (re-find #"connectionParams" s))))
returns (" connectionParams: --NO-MATCH--")
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.
So I was using the 0.13 graphiql.html
file but the 0.12 interpolation 🙂
Ouch! The merits of lein clean
...
Do you find that AOT compilation helps server startup enough to offset the problems it often causes?
We deploy as Uberjars but w/o AOT.
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
I'm wondering if there's a way to convert the map automatically to simple-keywords, since returning qualified-keywords doesn't seem like an option
Maybe this is what you are looking for: https://lacinia.readthedocs.io/en/latest/resolve/attach.html#resolver-factories
Bit hazy on the details tho
Thanks, I'll take a look at that
Just an idea, haven’t tried that… when you create lacinia’s GraphQL schema, you attach you resolvers. There you could wrap all resolvers with a function that will handle the mapping. Here you have endless possibilities like, stripping the namespace part of all map keys that are keywords or use a map where you define these mappings (e.g. {:person/id :person :person/name :name}
)
… or use GraphQL directives to specify this mapping in the schema. I did something like that for checking authorisation. If you are interested in details, I can put something together…
are you using lacinia-pedestal
? You might also put that into an interceptor.
If GraphQL compatibility is not an issue you might look at https://github.com/wilkerlucio/pathom which gives you the full potential of EDN an thus namespaced keys.
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 🙂