Edits to short directives article#4979
Conversation
|
@trevor-scheer @glasser Hopefully a pretty quick one for whoever |
| description: Using schema directives to transform schema types, fields, and arguments | ||
| title: Directives | ||
| sidebar_title: Directives | ||
| description: Configure schema types, fields, and arguments |
There was a problem hiding this comment.
So there are essentially two kinds of directives in GraphQL: executable directives that you put in your query/mutation (like @skip), and schema directives that you put in your schema (like @deprecated). I mean the spec doesn't literally differentiate between them but in practice most directives are declared to go on a set of executable locations or a set of schema locations.
Previously this document specifically talked about "schema directives" a lot. Though it then mentioned @skip and @include anyway.
Changing the document to be about directives in general does make sense to me, but I think at some point you should actually explain that some directives go on operations and some on schemas? Especially since at some point in the file you do start talking specifically about defining schema directives. (ie, these docs don't explain how you'd write code to react to an executable directive, which perhaps may just be that we don't have a great pattern, I dunno.)
There was a problem hiding this comment.
Good points here. Revisiting.
|
|
||
| ## Valid locations | ||
|
|
||
| Each directive's definition specifies _where_ it can appear in a GraphQL document. For example, here's the GraphQL spec's definition of the `@deprecated` directive: |
There was a problem hiding this comment.
You should probably explain somewhere that directives have definitions, which are part of the schema; a directive needs to be defined in the schema in order for you to use it in that schema or in an operation being validated against the schema.
a21c724 to
0238408
Compare
|
@glasser lemme know how this looks |
glasser
left a comment
There was a problem hiding this comment.
btw as a heads up for when you get to the schema directives page: AS now specifically links in an outdated version of graphql-tools (v4). You may want to note that if you want to use a newer version of the schema directives code you can use @graphql-tools/schema yourself and call makeExecutableSchema. See #4810 (comment) for details (hopefully I can reduce the number of caveats)
| ``` | ||
|
|
||
| This indicates that `@deprecated` can decorate either a schema field definition (as shown in the example above) or an enum value definition (as shown here): | ||
| This indicates that `@deprecated` can decorate either a `SCHEMA_FIELD` definition (as shown at the top of the article) or a schema `ENUM_VALUE` definition (as shown here): |
There was a problem hiding this comment.
I think you mistyped "schema FIELD_DEFINITION"?
| Each directive's definition specifies _where_ it can appear in a GraphQL document. For example, here's the GraphQL spec's definition of the `@deprecated` directive: | ||
| Each directive can only appear in _certain_ locations within a GraphQL schema or operation. These locations are listed in the directive's definition. | ||
|
|
||
| For example, here's the GraphQL spec's definition of the `@deprecated` directive: |
There was a problem hiding this comment.
It may or may not be interesting that this is likely to change to add some more locations (graphql/graphql-spec#805) and that in fact graphql-js and others already support more locations...
There was a problem hiding this comment.
Ah, hmm. I'll keep like this for now to match 2018 and might revisit this with additional perspective after cleaning up the big article
| | `@include(if: Boolean!)` | If `false`, the decorated field or fragment in an operation is _not_ resolved by the GraphQL server. | | ||
|
|
||
| GraphQL provides several default directives: [`@deprecated`](http://facebook.github.io/graphql/draft/#sec--deprecated), [`@skip`](http://facebook.github.io/graphql/draft/#sec--skip), and [`@include`](http://facebook.github.io/graphql/draft/#sec--include). | ||
| ## Custom directives |
There was a problem hiding this comment.
I think this section should still have "schema" in the name since that's what it's about.
|
|
||
| ### Schema directives vs. operation directives | ||
|
|
||
| Usually, a given directive appears _exclusively_ in GraphQL schemas or _exclusively_ in GraphQL operations (rarely both, although the spec allows this). |
There was a problem hiding this comment.
Note that the implementing directives page calls these query directives. I think moving towards operation rather than query is good, though, and I think you said you were heading to that page next.
There was a problem hiding this comment.
Cool, I'll replicate this change over there.
| ### Creating | ||
|
|
||
| ## Using custom schema directives | ||
| See [Implementing directives](/schema/creating-directives/). |
There was a problem hiding this comment.
I'm not sure that this subsection really helps much.
How about dropping the subsections and just starting the section with something like:
You can extend Apollo Server with custom schema directives created by you or a third party. To do so, add a definition for the directive to your schema. If you'd like your server to find all the usages of your directive during server startup and react to them in some way, you can implement a
SchemaDirectiveVisitorand pass it tonew ApolloServer. For full details on everything aSchemaDirectiveVisitorcan do, see the section on implementing directives.
0238408 to
fa76767
Compare
fa76767 to
288360b
Compare
Setting the stage for editing the much larger custom directives article