Graphql-js: Allow custom directives

[aackerman]

GraphQLSchema does not expose the use of custom directives. Based on the spec, the @skip and @include directives are required and appears to allow for custom directives.

The GraphQLSchemaConfig type doesn't allow a list of directives, and neither does the GraphQLSchema allow directives through the constructor, but it is possible to set the _directives prop on the GraphQLSchema type, so it's technically possible but not exposed.

[leebyron]

Can you explain more concretely what custom directives you wish to provide and how you would imagine implementing them?

I'm curious because we're actually considering a change that removes directives from the schema completely.

[aackerman]

It seemed like a gap in the implementation, and I'm interested in contributing. I don't have any concrete examples at this time.

[leebyron]

Oh ok, I understand.

To be clear, directives are not designed to be extended by users of graphql, but by future versions of graphql core itself.

That's the reason we're considering removing them from schema. It's too confusing as schema is something a user of graphql defines and produces, and directives being accessible from the same portion of code is the thing that doesn't look like the others.

[sevki]

I think the grammar is confusing for people reading graphql for the first time, if you replace the @ with a . they are practically chained calls which is well known pattern

[leebyron]

I'm not sure I agree chained calls is a well known pattern unless you've used Facebook's pre-spec graphql. Chained calls were replaced by field arguments. Directives is an entirely new concept

[leebyron]

Closing this now as we've determined that user-supplied custom directives is a non-goal for graphql-js at this time.

[oriweingart]

Check this extention for custom directive:
https://github.com/lirown/graphql-custom-directive

[dschnare]

@leebyron Hmm. This doesn't sit well with me. Directives are a great way for graphql server administrators to provide custom functionality to their graphql users.

From the spec:

GraphQL servers define what directives they support. For each usage of a directive, the directive must be available on that server.

This seems to be that so long as a directive can be found on the server the users of graphql should be fully capable of using said directive. Hence, there ought to be a way for graphql server administrators to add/register directives.

From my review of the source it appears that when instantiating a GraphQLSchema you can specify custom directives as part of the GraphQLSchemaConfig#directives config property, but there is no way to actually execute said directives (at least from what I can tell).

For those looking for similar functionality and not an outdated repo, try giving https://github.com/smooth-code/graphql-directive a look. Just don't expect this to work forever.

[AlbertMarashi]

TLDR

Use this package to add custom directive support: https://github.com/smooth-code/graphql-directive

[xamgore]

Can you explain more concretely what custom directives you wish to provide and how you would imagine implementing them? @leebyron

Well, I use graphql-faker to define a schema with fake data. Frontend developers feel really great with it, cause it consists of easy-to-run-graphql-server and there is no need in heavy backend, databases, etc.

$ graphql-faker --open ./schema.graphql 

To fake data, schema must contain some additional directives: @fake(…) and @examples(…). They describe the true nature of entities: names, emails, phone numbers, …

type Query {
  hello: String!  @fake(type: firstName)
}

As a GraphQL API developer, I write the following code:

import { graphql, buildSchema } from 'graphql'

const schema = buildSchema(fs.readFileSync('./schema.graphql', 'utf8'))

app.use('/graphql', graphqlHTTP({ schema, rootValue }))

And I want the graphql parser just to ignore those @fake and @examples directives, and have a single schema.graphql file both for graphql-faker, and for my graphql API.

As a bypass I wrote a regex, though it's not a reliable way (context-grammar, braces, all that stuff), resolving custom directives after grammar parsing is better.

[IvanGoncharov]

@xamgore Yes, it's a valid issue but it's not related to this issue.
Can you please open a new issue?