This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (2)
- # announcements (3)
- # beginners (95)
- # bitcoin (1)
- # cider (18)
- # cljdoc (9)
- # cljs-dev (8)
- # clojure (55)
- # clojure-austin (1)
- # clojure-berlin (4)
- # clojure-italy (21)
- # clojure-nl (1)
- # clojure-russia (2)
- # clojure-spec (47)
- # clojure-uk (31)
- # clojurescript (19)
- # component (8)
- # cursive (5)
- # data-science (2)
- # datomic (33)
- # emacs (7)
- # events (1)
- # figwheel (8)
- # fulcro (16)
- # graphql (27)
- # hyperfiddle (5)
- # jobs (1)
- # jobs-discuss (85)
- # keechma (7)
- # luminus (11)
- # mount (6)
- # off-topic (23)
- # onyx (1)
- # re-frame (4)
- # shadow-cljs (29)
- # specter (19)
- # tools-deps (11)
- # uncomplicate (3)
@hlship Has there been any discussion of implementing custom directives (particularly schema directives) in Lacinia?
I’ve been looking for this in the issue tracker, seems like the answer so far is no. Have you found a use case for schema directives? Some frameworks use them but I’m not sure if they are an anti pattern. Also I believe the spec says that custom directives should not be supported?
Not sure what you mean that the spec says they should not be supported. They are part of the spec.
Sorry, mistyped. I recall but not 100% sure that the spec provides two built in directives, and state that there is no envisioned need for custom directives yet, and they are discouraged.
But in any case, seems like people actually use them, so I just wonder what the use cases are?
No, that's inaccurate. The spec has three built-in directives: two query (`@skip` and
@include) and one schema (`@deprecated`). It fully supports adding additional query and schema directives as of June 2018.
Directives are useful because they are the primary mechanism by which most things can be extended in GraphQL, beyond the normal specification. Personally, I'm using them to generate clojure.spec specs.
Even just updating the parser to be compliant with the June 2018 spec would be useful. Currently, it chokes on valid GraphQL SDL.
Get me an issue and examples, I'd love to make this work in some way. At the very least, we need to be able to parse valid GraphQL SDL even if we don't quite know what to do with directives in the SDL.
So you are starting with the official SDL and parsing it, rather than going with the EDN flavor? I toyed with the idea of doing that but it seems it’s easier to start with EDN, the you can generate all you want directly from it.
This is for a library, not an application. It needs to ingest both Lacinia EDN and GraphQL SDL since both are commonly used.
Aaah, super cool then. We just started a new project in Clojure+Lacinia, and I am thinking similar thoughts. Is this a planned open source library?
I can (and have) make up my DSL for adding directives to Lacinia's EDN but I'd rather that be part of Lacinia itself.
I had a look at lacinias parser about custom directives some time age and it seems there are no visible (to me) extension points at the moment. Skip and include are hard coded in a few places.
Also IIRC the current SDL parser was written by someone else, so I don’t believe it’s a high priority for Walmart...
I, too, am waiting for reasonable use cases before figuring out how to implement custom directives. There's big questions about what data can be safely exposed to a directive, and what changes it can make to the schema. I think a precursor to this will be providing more specs about what's in the compiled schema and/or the parsed query data structures ... we've been loathe to document these since that locks us down from changing the structure going forward. That's why we've introduced the "preview api" for example; we still have the freedom to change the internal representations as long as the preview api is also updated.
Have you seen the Apollo docs on schema directives? Here is one of their articles: https://www.apollographql.com/docs/graphql-tools/schema-directives.html