Fork me on GitHub

@hlship do you know if theres a nice way to have camelcase in the edn schema and kebab case in the resolvers?


or should i just use the case converter libs?


I'm only asking because you can't have kebab case in the schema right?


Apologies if i'm wrong


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 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


Ill check out your version though for sure 馃槃


We have our own namespaces with such functions.


i think thats probably v similar to what you've done


@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.


@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)

(defn build-platform-schema []
  (-> (io/resource "graphql/platform-schema.edn")
      (lacinia-util/attach-resolvers {:resolve-viewer queries/viewer})
      (lacinia-schema/compile {:default-field-resolver field-name->kebab-case})))


The ->kebab-case function comes from [camel-snake-kebab.core :refer :all]


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.


In other words, provide "around advice" for a specific resolver, and not have to worry about the code being asynchronous, or returning a ResolveCommand.


I'm having a very frustrating day, maybe I'll work on that.