This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-07
Channels
- # bangalore-clj (2)
- # beginners (53)
- # boot (30)
- # cider (27)
- # clara (1)
- # cljs-dev (18)
- # cljsrn (16)
- # clojure (153)
- # clojure-brasil (1)
- # clojure-dusseldorf (5)
- # clojure-italy (20)
- # clojure-losangeles (3)
- # clojure-spec (4)
- # clojure-uk (177)
- # clojurescript (115)
- # component (4)
- # core-logic (1)
- # datomic (29)
- # emacs (9)
- # figwheel (2)
- # gorilla (1)
- # graphql (36)
- # hoplon (4)
- # jobs (1)
- # jobs-discuss (3)
- # juxt (2)
- # keechma (22)
- # lumo (4)
- # off-topic (1)
- # onyx (17)
- # parinfer (96)
- # protorepl (10)
- # re-frame (31)
- # reagent (14)
- # ring-swagger (17)
- # spacemacs (32)
Apologies if this is old ground covered before, but is there any desire (or hard reason not) to relax the graphql restriction on hyphens in keys within a Clojure implementation like Lacinia?
I would like to use Lacinia from an existing clojure+Clojurescript project but I don't want to have a load of key renaming just to satisfy what is, to Clojure, an arbitrary restriction
I understand it's there to keep JSON and JavaScript happy, but if they don't exist in my world can I retain my Clojure naming conventions?
@oliy this would break tools like GraphIQL, Apollo client, Relay, etc. It seems to me that adopting javascript’s/graphql’s naming conventions in this case is reasonable
You wouldn’t want to maintain your own fork of whatever GraphQL-related tools you are using just so they can support clojure naming conventions
If you want to maintain Clojure conventions/semantics on the frontend and the backend, you might want to look into Om Next instead
@oliy note that you should be able to automate the conversation from and to clojure naming conventions
@hmaurer thanks for your thoughts - I'm brand new to all this so didn't even know some of those things existed. It's a good point and well made
Disclaimer: I am new too and haven’t experimented with Om Next at all, so take what I say with a grain of salt! 🙂
I was actually considering something more along the lines of the euroclojure keynote to generate the conversion at compile time, as I know the from and to schemas in advance
Renaming keys at runtime would add back all the CPU overhead I was hoping to reduce by using graphql :)
I don’t know what your project is but the cost of converting keys at runtime should be completely marginal
Unless your input payloads are incredibly big for some reason, we’re likely talking microseconds here
The idea of graphql was to reduce those tens of megabytes by an order of magnitude, it may be enough for decent browser performance
So there is a lot of data, and we're trying to cut it back to the minimum required to render a view
Should be yeah, and in that case I think the conversion to and from javascript naming convention on fields should be cheap
You’re welcome. Tag me if you want to discuss; I am working on a Lacinia app too so I might have stumbled upon the same problem you will encounter @oliy
The Lacinia docs give examples where an enum is used as an query argument type, but I didn't see any examples using a custom object. Does anyone have an example using a custom object, or even better a list of custom objects, as argument type? Until now I've gotten along with only :type String
and :type (list String)
When trying get an exception complaining argument X of field Y in type `QueryRoot' is not a valid argument type. Perhaps I am not understanding the GraphQL spec correctly, but seems custom object types should be OK.
:args {:myStringArg {:type String}}
works fine.
:args {:badArgType {:type :myObject}}
doesn't.
Input objects don't have resolvers, and fields are restricted to: scalars, enums, input objects (and lists thereof).
Thank you.
If you are having problems upgrading to lacinia-pedestal 0.3.0, our apologies. We are seeing some problems upgrading our code to the latest versions. In the future, we will perform an internal soft-release and ensure that lacinia and lacinia-pedestal are being used in production internally before making a public release. Specific problems: - Need a dependency on org.clojure/test.check 0.9.0 - Extraction of data from request has changed, and does not match documentation