graphql 2017-10-19 | Slack Archive

guy09:10:31

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

guy09:10:44

or should i just use the case converter libs?

guy09:10:06

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

guy09:10:15

Apologies if i'm wrong

andrewtropin13:10:20

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.

andrewtropin13:10:28

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.

guy13:10:21

Thanks!

guy13:10:56

I was just thinking of doing a standard camelcase schema but then attaching a camelcase converter where u attach resolvers. @andrewtropin

guy13:10:24

Ill check out your version though for sure 😄

guy13:10:06

using this lib https://github.com/qerub/camel-snake-kebab

andrewtropin14:10:30

We have our own namespaces with such functions.

guy13:10:16

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

hlship21:10:57

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

boubalou12:10:23

Hey @hlship, could you elaborate on this :dashed-keywords option? (I looked at the code and couldn’t 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’t figure out a better way other than calling the same method in every resolver to transform the result into the expected Lacinia’s schema camelCase casing.

boubalou12:10:21

I wonder if there is an hidden gem somewhere that I didn’t see on which we could delegate this task ala middleware concept.

hlship16:10:50

This is part of the solution: http://walmartlabs.github.io/lacinia/com.walmartlabs.lacinia.schema.html#var-hyphenating-default-field-resolver

guy10:10:44

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

boubalou12:10:29

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

boubalou12:10:53

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

guy13:10:47

Thanks @U4FGRRHDE

guy13:10:24

guy13:10:00

Hmm maybe im confused. I thought we could use var-hyphenating-default-field-resolver instead of the usual one.

boubalou13:10:38

Depends on your needs, I guess. The hyphenating-default resovler converts underscores to hyphens, not camelCase to kebab-case.

guy13:10:05

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.

guy13:10:55

You've been very helpful @U4FGRRHDE cheers! Sorry that i've not been very easy to understand

hlship21:10:24

There's a bit that can be done by adding wrappers around resolver functions, before attaching resolvers to the schema.

hlship21:10:53

Perhaps you could post a tiny schema and how you would like things to look, at least, inside a resolver?

hlship21:10:11

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.

hlship21:10:31

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

hlship21:10:21

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

2017-10-19

Channels