Fork me on GitHub
#graphql
<
2021-12-06
>
rickmoynihan15:12:03

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

rickmoynihan15:12:06

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.

Lennart Buit15:12:08

There is inject-resolvers , takes a map of schema coordinates (`TypeName/fieldName`) and a normal resolver function

👀 1
rickmoynihan15:12:33

Thanks that looks like what I need

rickmoynihan17:12:27

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.

hlship17:12:08

You're seeing the evolution of the library over time - I now always use inject-resolvers.

👍 1
rickmoynihan10:12:08

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?!

rickmoynihan10:12:33

ahh I see “locations” is a concept from the graphql spec 👀

rickmoynihan10:12:19

Does lacinia support all the specified locations?

rickmoynihan10:12:03

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.

rickmoynihan10:12:32

Ahh cool the lacinia SDL parser supports directive defs 👌

directive @foo(
  foo: String = "foo"
) on FIELD_DEFINITION | ENUM_VALUE

Lennart Buit18:12:42

There is no consensus on standardizing custom directives in introspection

Lennart Buit18:12:37

Some directives have custom introspection schema, @deprecated for example

Lennart Buit18:12:55

That said, some GraphQL implementations, most notably Java and .net, have semi standardized directive introspection schemas

Lennart Buit18:12:00

Finally, some servers work around this. For example Apollo Federation has a top level ‘sdl’ query. SDL does support directives

rickmoynihan09:12:57

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

rickmoynihan09:12:59

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?

Lennart Buit09:12:11

Hmm interesting; directive definitions do appear to have an introspection schema indeed. I stand corrected