This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-07-24
Channels
- # announcements (2)
- # aws (2)
- # babashka (1)
- # beginners (87)
- # boot (1)
- # calva (42)
- # clj-kondo (18)
- # cljdoc (5)
- # cljsjs (1)
- # cljsrn (1)
- # clojars (16)
- # clojure (222)
- # clojure-dev (30)
- # clojure-europe (17)
- # clojure-gamedev (2)
- # clojure-hungary (10)
- # clojure-italy (6)
- # clojure-nl (21)
- # clojure-spec (9)
- # clojure-uk (111)
- # clojuredesign-podcast (1)
- # clojurescript (99)
- # code-reviews (1)
- # conjure (18)
- # cursive (11)
- # datomic (22)
- # emacs (1)
- # events (3)
- # figwheel-main (3)
- # fulcro (14)
- # graalvm (41)
- # graphql (16)
- # helix (12)
- # juxt (1)
- # kaocha (56)
- # keechma (1)
- # meander (77)
- # observability (1)
- # off-topic (29)
- # pathom (3)
- # re-frame (4)
- # reagent (3)
- # reitit (1)
- # remote-jobs (3)
- # reveal (9)
- # shadow-cljs (45)
- # spacemacs (43)
- # sql (28)
- # tools-deps (14)
- # vim (1)
- # xtdb (26)
- # yada (1)
Am I correct in concluding that if you migrated to lacinia.pedestal2, that the query extraction no longer calls the extract-query multimethod for query extraction? We were extending that to parse queries sent in multipart requests (graphql upload spec)
Here in lacinia.pedestal: https://github.com/walmartlabs/lacinia-pedestal/blob/92945c34486fc52916069963b6f87ee4e4dcbd58/src/com/walmartlabs/lacinia/pedestal.clj#L169
Here in lacinia.pedestal2 a block on content type being application/json: https://github.com/walmartlabs/lacinia-pedestal/blob/92945c34486fc52916069963b6f87ee4e4dcbd58/src/com/walmartlabs/lacinia/pedestal2.clj#L49
And the new data interceptor not invoking an extendable multimethod: https://github.com/walmartlabs/lacinia-pedestal/blob/92945c34486fc52916069963b6f87ee4e4dcbd58/src/com/walmartlabs/lacinia/pedestal2.clj#L64
(I don’t want to be that guy always complaining, still loving the library. I will offer pull requests when applicable 🙂 )
Yes, the new namespace is simpler, and does less. You can swap in some of the old interceptors however, or mix and match pretty easily.
Right, so that means replacing both interceptors. That sounds fair, we were already replacing body-data to deal with multipart requests, so I guess we’ll also replace the graphql-data interceptor with the old / a custom implementation when this library is used with pedestal2 interceptors
Extending that multimethod was a nice sneaky solution while it lasted, but I can see your reasoning of not wanting two extension methods (replacement of interceptors and extending of multimethods)
In other questions: Could it be that enum transformers are not called to serialize default values?
When I add a custom scalar, say a Decimal, I can put a decimal literal in my schema.edn as a default-value, and in introspection, this default value will have been serialized by my custom scalar serialize function.
Now, with enums, I have an enum transformer that adds a namespace/kebab-cases the constant. Now, I expected to be able to add a ns-qualified kebab-cased keyword in schema.edn as a default-value, and, in introspection, get my serialize function called for this enum. This, however, appears to not be the case and instead I just get (name enum-member) in defaultValue of an introspection query. That trips up GraphQL playground, as a kebab-cased string is not a member of that enum ^^
Again, don’t want to be a burden. I am willing to provide issues, patches, or whatever to contribute 🙂. My reasoning: rather report a false positive, than not report a legit bug 🙂.
Sanity check: The expected behaviour is that you put a ‘parsed’ enum value as default-value in schema.edn?
So in this case, a ns-qualified kebab-cased keyword
If so, I can take a stab at it
I have to say, it is quite easy to trace and fix problems in lacinia as a relative outsider 🙂.