This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-06
Channels
- # adventofcode (106)
- # aleph (1)
- # announcements (1)
- # asami (14)
- # babashka (120)
- # beginners (54)
- # calva (106)
- # chlorine-clover (33)
- # clj-kondo (5)
- # cljdoc (3)
- # cljs-dev (3)
- # clojure (92)
- # clojure-android (1)
- # clojure-australia (2)
- # clojure-europe (24)
- # clojure-italy (3)
- # clojure-nl (5)
- # clojure-uk (16)
- # clojuredesign-podcast (1)
- # clojurescript (29)
- # code-reviews (58)
- # conjure (16)
- # core-logic (4)
- # cursive (9)
- # datalevin (2)
- # graphql (20)
- # gratitude (7)
- # jackdaw (11)
- # java (9)
- # jobs (2)
- # lsp (23)
- # minecraft (1)
- # missionary (28)
- # off-topic (5)
- # polylith (5)
- # react (1)
- # reagent (12)
- # releases (1)
- # remote-jobs (4)
- # reveal (7)
- # shadow-cljs (8)
- # slack-help (1)
- # tools-deps (11)
- # vim (6)
If your schema is written in SDL, and you’re using parse-schema
how are you supposed to attach the resolvers?
The guide still seems to document passing them in the attach
map however the docstring says the :resolvers
key is now deprecated.
I tried using attach-resolvers
but I’m not sure what convention you’re supposed to use to identify them… I tried :Query/myfield
and :query/myfield
and neither seemed to work
It looks like attach-resolvers
isn’t right, because it expects a :resolve
key to be present… in the schema edn; but parse-schema
doesn’t set it.
There is inject-resolvers
, takes a map of schema coordinates (`TypeName/fieldName`) and a normal resolver function
Thanks that looks like what I need
I’m curious about adding some type and field level directives. To essentially provide a mapping of annotations to other identifiers in the backend systems. Does lacinia provide any good ways to access these in resolvers, or to post pre/post process requests and responses? The docs seem to indicate this is an area under development.
You're seeing the evolution of the library over time - I now always use inject-resolvers.
Also look at the :apply-field-directives option to compile (https://walmartlabs.github.io/apidocs/lacinia/com.walmartlabs.lacinia.schema.html#var-compile)
Thanks.
I’m still trying to figure out precisely how directives are supposed to work in graphql and lacinia.
Am I right that the :locations
keyword states where a given directive is allowed to occur in the AST?
In which case I’m assuming the allowed values are:
• :field-definition
for annotating a field
• :enum
for annotating an enum
• :object
for annotating a type?!
ahh I see “locations” is a concept from the graphql spec 👀
Does lacinia support all the specified locations?
I see from the docs also this: > Introspection hasn’t caught up to to these changes; custom directives are not identified, nor are directives on elements. I’m assuming this is why:
__schema {
directives {
name
description
locations
args {
name
description
}
}
does not list my :directive-defs
Are there plans to add support for introspection on directives? Strictly speaking I probably don’t require this at the minute, but I can imagine applications for it.Ahh cool the lacinia SDL parser supports directive defs 👌
directive @foo(
foo: String = "foo"
) on FIELD_DEFINITION | ENUM_VALUE
There is no consensus on standardizing custom directives in introspection
Some directives have custom introspection schema, @deprecated
for example
That said, some GraphQL implementations, most notably Java and .net, have semi standardized directive introspection schemas
Finally, some servers work around this. For example Apollo Federation has a top level ‘sdl’ query. SDL does support directives
@UDF11HLKC Thanks for linking to that discussion, there are some interesting points there… though I’m not sure I follow all of them…
> There is no consensus on standardizing custom directives in introspection
is that true though? The latest draft of the spec includes quite a lot on the __Directive
type in particular it states:
https://spec.graphql.org/draft/#sec-The-__Directive-Type
> This includes both any built-in directive and any custom directive.
And as far as I can tell the __Directive
type has been documented to some extent in every version of the spec since the first spec in July 2015.
I understand many aspects of Directives are unstandardised; but it seems this particular one is, and isn’t yet supported in lacinia… or am I missing something?
Hmm interesting; directive definitions do appear to have an introspection schema indeed. I stand corrected