This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-19
Channels
- # aws (4)
- # aws-lambda (2)
- # beginners (67)
- # boot (38)
- # cider (32)
- # cljs-dev (12)
- # cljsrn (2)
- # clojars (2)
- # clojure (190)
- # clojure-chicago (1)
- # clojure-dusseldorf (2)
- # clojure-germany (1)
- # clojure-greece (3)
- # clojure-italy (5)
- # clojure-russia (6)
- # clojure-spec (47)
- # clojure-uk (10)
- # clojurescript (59)
- # cursive (9)
- # data-science (14)
- # datomic (24)
- # devops (16)
- # emacs (8)
- # fulcro (25)
- # graphql (30)
- # hoplon (123)
- # juxt (15)
- # lambdaisland (2)
- # leiningen (4)
- # luminus (6)
- # lumo (9)
- # off-topic (11)
- # om (7)
- # onyx (8)
- # re-frame (14)
- # reagent (5)
- # ring-swagger (5)
- # shadow-cljs (46)
- # spacemacs (41)
- # specter (8)
- # testing (8)
- # unrepl (31)
- # yada (18)
@hlship do you know if theres a nice way to have camelcase in the edn schema and kebab case in the resolvers?
We did a fork, which allows to use kebab-case in the schema, but we use two schemas to parse queries, first one is a kebab-cased and second is auto-generated snake_cased schema. We decide which schema to use based on content-type header. If content-type is application/json we use snake_cased schema, it allows to use graphiql for our /graphql endpoint, but inside our code kebab-case is everywhere.
It's pretty hacky solution and works only with https://github.com/urbestteam/lacinia-hyphen I don't recommend to use it, because it's not battle tested, but it can help you to figure out, how to deal with keys transformations in schemas.
I was just thinking of doing a standard camelcase schema but then attaching a camelcase converter where u attach resolvers. @andrewtropin
using this lib https://github.com/qerub/camel-snake-kebab
We have our own namespaces with such functions.
@guy What do you mean by "kebab case in the resolvers"? Resolvers take input and output. Earlier versions of Lacinia had different logic for the default resolver, that would convert under_score_names to :dashed-keywords (that's still available as an option, but is no longer the default).
Hey @hlship, could you elaborate on this :dashed-keywords
option? (I looked at the code and couldn鈥檛 find any reference there). I want, on our side, to keep our kebab-casing all over the place until the last moment when returning the result to the resolver but I couldn鈥檛 figure out a better way other than calling the same method in every resolver to transform the result into the expected Lacinia鈥檚 schema camelCase
casing.
I wonder if there is an hidden gem somewhere that I didn鈥檛 see on which we could delegate this task ala middleware concept.
This is part of the solution: http://walmartlabs.github.io/lacinia/com.walmartlabs.lacinia.schema.html#var-hyphenating-default-field-resolver
@hlship sorry for the late reply, How would i try out the hyphenating version? It does exactly what i want it to do, same use case as @U4FGRRHDE above.
Here is my schema.clj
NS using the field resolver config:
(defn- field-name->kebab-case [field-name]
(-> (->kebab-case field-name)
lacinia-schema/default-field-resolver))
(defn build-platform-schema []
(-> (io/resource "graphql/platform-schema.edn")
slurp
edn/read-string
(lacinia-util/attach-resolvers {:resolve-viewer queries/viewer})
(lacinia-schema/compile {:default-field-resolver field-name->kebab-case})))
Thanks @U4FGRRHDE
Hmm maybe im confused. I thought we could use var-hyphenating-default-field-resolver instead of the usual one.
Depends on your needs, I guess. The hyphenating-default resovler converts underscores to hyphens, not camelCase to kebab-case.
Ah yes sorry total brain fart my end. I was just going to update my schema to use _ instead of camel case. Then I could just use their hyphenating-default resovler, so i wouldnt have to convert it manually myself.
You've been very helpful @U4FGRRHDE cheers! Sorry that i've not been very easy to understand
There's a bit that can be done by adding wrappers around resolver functions, before attaching resolvers to the schema.
Perhaps you could post a tiny schema and how you would like things to look, at least, inside a resolver?
I was just thinking it might be nice if the framework supplied a macro or function to easily wrap a resolver and hide the existence of the ResolverResult, etc.