This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-17
Channels
- # 100-days-of-code (5)
- # announcements (13)
- # beginners (98)
- # boot (19)
- # cider (10)
- # cljdoc (32)
- # clojure (142)
- # clojure-dev (37)
- # clojure-italy (3)
- # clojure-nl (2)
- # clojure-spec (30)
- # clojure-uk (18)
- # clojurescript (28)
- # cursive (8)
- # datomic (25)
- # duct (18)
- # editors (5)
- # emacs (39)
- # events (4)
- # figwheel (7)
- # figwheel-main (5)
- # fulcro (38)
- # graphql (19)
- # jobs-discuss (1)
- # jobs-rus (7)
- # keechma (1)
- # lumo (47)
- # off-topic (28)
- # om-next (3)
- # parinfer (3)
- # re-frame (18)
- # reagent (37)
- # reitit (8)
- # shadow-cljs (101)
- # specter (7)
- # tools-deps (8)
- # vim (1)
Hi, I'm getting Failed to compile GraphQL Schema. Got message: clojure.lang.ExceptionInfo: Resolver specified in schema not provided. {:reference :default-value, :callbacks (:interfaces :root-schema :of-type :enum-values :input-fields :fields :possible-types :root-type :nested-type)}
What I find bizarre is that I've checked out the commit way back when I first committed a test to check our schema compiles and it now fails, I'm sure it passed when I checked it in
I don't know if it's relevant but we're using Relay, which needs a graphql schema, so we're also using Lacinia parser/parse-schema rather than EDN
If you were using EDN, that error means that you had a :resolve :my-resolver-fn
somewhere, and you’re not attaching a resolver function anywhere.
Nothing to do with .m2 or anything else BTW. This is Lacinia complaining that your schema is invalid.
Hey friends, i’m trying to get a handle on what the current state of consuming graphql (from AWS AppSync, not Lacinia if it matters) from clojurescript is. I’m not sure if this is one of the scenarios where nobody does it so there aren’t resources on the web or if its the other scenario where its so trivial to do that nobody bothered to write a blog post on how to do it. Does anyone have pointers to an example that has mutations, queries, and subscriptions?
@alee That looks to be in the part of the code that applies some Introspection resolvers to the Introspection types (these are merged into the schema provided by the application). I can't imagine a scenario where this should happen; if there's any way you could shave down your SDL schema so that it still manifests this problem I'd be happy to dig down into it.
Have you integrated it with reagent at all? I know you’ve done work with React Native.
@joe.lane Yes, Apollo is easy to use with Reagent. Unfortunately, I don't have open-source code on this that I can share as the only times I've written Reagent wrappers for Apollo were for consulting clients. I'd like to make a library for this; the biggest issue is just figuring out how to package all of the Apollo deps. Anyway, the gist of it is that you can wrap ApolloClient's watchQuery
(not ApolloReact) with reagent.ratom/make-reaction
. Then you can treat query results like reactive atoms (watching components will rerender when query results change).
My company has open-sourced artemis, based on a lot of ideas from apollo, it's minimal but might be useful: http://docs.workframe.com/artemis/current/index.html