At the start of working with GraphQL, the mandatory typing system was frustrating because we didn't want to fall back to having a generic "attributes: JSON" field. Most objects have common "core" fields, and customer-specific configurable fields.
Just think how helpful it would be to properly fields so developers know what to do without ever needing to leave the code? That’s powerful in and of itself.I had a similar situation, and took a different approach by adding new schema fields at a higher level of abstraction on top of the data.Ĭontext: our application has configurable/dynamic data structure, and there is a lot of meta-programming. Having them there not only gives developers the benefit of extra control, but an overall better developer experience. That’s the sort of efficiency and that makes the GraphQL API so quick and ultimately more friendly to work with.Īnd if you’re building a GraphQL API, then be sure to include these directives to the introspection query. We already have a lot of control with GraphQL schema, and directives give us even more fine-grained control to get exactly what we want out of queries. Again, I believe directives are a sort of unsung hero that gets overshadowed by other GraphQL features. So that’s a high-level look at GraphQL directives.
#Graphql conditional fragment code
It is a custom GraphQL directive that has both code and schema-first support for annotating which of an API can be consumed in public. If you’re looking for an example custom directive, and how it’s created, take a look at GraphQL Public Schema. It’s recommended that custom directives have a prefixed name to prevent collisions with other added directives. Using the last example and the proposal defined in RFC #822, a scalar for EmailAddress would be defined in the schema like so: scalar EmailAddress "") It’s set to be used by custom scalar implementations and take a url argument that should point to a specification for the scalar.įor example, if we add a custom scalar for email address, we will want to pass the URL to the specification for the regex we use as part of that. query getUsers($showName: Boolean) is the fourth of the directives and is currently part of the working draft. Since it’s conditional, it makes sense to use a variable in the query to check for truthiness.įor example, if the variable in the following examples is truthy, then the name field will be included in the query response. directive, true to its name, allows us to conditional include fields by passing an if argument. If you’re following GraphQL closely, you will also notice two additional directives were merged to the JavaScript implementation that you can try today - and These aren’t part of the official spec just yet while the community tests them in real world applications. GraphQL boasts four main directives as defined in the specification working draft, with one of them unreleased as a working draft.
In short, directives can be used for the purposes of metadata, runtime hints, runtime parsing (like returning dates in a specific format), and extended descriptions (like deprecated). Schema directives are used when the schema is generated, and operation directives run when a query is executed. Or, in simple terms, directives are either based on schema or operation. Specifically, directives can be used by consumer operations (such as a query), and by the underlying schema itself. The GraphQL specification defines what directives are, and the location of where they can be used. With GraphQL directives, though, we can choose to include or skip those fields. If you hide two or three columns then there’s really no need to fetch the data for those cells. Let’s imagine an application where you have the option to customize the columns shown in a table. They are extremely useful if you are working with a dynamic front-end because you have the control to reduce the response payload depending on what the user is interacting with. Let’s explore working with GraphQL’s built-in schema and operation directives that all GraphQL spec compliant APIs must implement. Directives are one of GraphQL’s best - and most unspoken - features.
0 kommentar(er)
