Add directives to a Type or Field

[davidbarratt]

It seems like directives can be added to a Type or a Field if using the Type Language. I need to be able to add directives via the $config options as part of the constructor of a type or a field, but it doesn't look like this is possible?

[davidbarratt]

It looks like if you add a deprecationReason to a field, then you get the @deprecated Directive. But it doesn't look like you can arbitrarily set directives.

I think it might be more useful if deprecaitonReason was removed and instead you could set any directive (that can be set on a schema?).

[shmax]

Aren't directives a construct in the query itself, and not the schema definition?

It seems like directives can be added to a Type or a Field if using the Type Language.

Can you provide a sample of what that looks like?

[davidbarratt]

I looked into graphql/graphql-js and this seems to be a problem there too... so probably not an issue for this repo.

The GraphQL spec doesn't make a distiction between "Query" directives (i.e. directives you use when making a query) and "Schema" directives (i.e. directives you use when constructing a schema).

For instance @include is a Query directive but @deprecated is a Schema directive.

Custom directives are supported in this library, but only for use as Query directives, not as Schema directives (although, they are supported as part of the Type Language). So if I create a Schema directive like @key that can't be "used" on any of the types because there is no way to apply it.

The only schema directive you can apply is @deprecated by supplying a deprecatedReason in the config of a type.

[vladar]

So if I create a Schema directive like @key that can't be "used" on any of the types because there is no way to apply it.

If you create your schema via SDL then directives should be accessible on the type via related AST node:

graphql-php/src/Type/Definition/ObjectType.php

Lines 57 to 63 in ea011cf

	class ObjectType extends Type implements OutputType, CompositeType, NullableType, NamedType
	{
	/** @var ObjectTypeDefinitionNode|null */
	public $astNode;
	/** @var ObjectTypeExtensionNode[] */
	public $extensionASTNodes;

[davidbarratt]

@vladar right, I understand, I'm saying that's the only way to do it, you can't add them as part of the config when constructing the object.

[vladar]

Can you please share what is your use case? What are you trying to achieve with directives in the config?

[davidbarratt]

I'm writting a GraphQL extension for MediaWiki and this uses PHP objects so that the schema can be passed to other extensions for modification.

I'm also looking to implement Apollo Federation which relies on schema directives.

The work-around I came up with is extend ObjecType with custom config and ignore the directives. It's a non-standard approach, but I think it should do the trick.

[vladar]

Reference implementation has a concept of extensions (via graphql/graphql-js#1527). Feel free to open a PR with a port of this graphql-js PR: graphql/graphql-js#2097

[terion-labs]

@vladar primary usecases are server-side directives, such as for lighthouse or apollo federation and others. E.g. schema can be generated programatically, printed and then passed to lighthouse, apollo, etc. It is really a problem and design flaw that directives can't be added programmatically

[dolfje]

I don't know if it is exactly the same, But the following schema

directive @field on FIELD  
type Query  {
	data: String @field
}

With the following parsing of that schema (Now the code is linearly, but normally the $ast is cached, so the parsing should not be done multiple times)

$document = Parser::parse($contents);
$ast = AST::toArray($document), true);
$document = AST::fromArray($ast);
$schema = BuildSchema::build($document);

Then I have no knowledge of the directives with a custom resolver. ResolveInfo constains the ObjectType. But it doesn't have the ast and it nowhere contains the directive information.

So I cannot use the directive information inside the resolver.

[spawnia]

Directives are a vehicle of the schema definition language. It is possible to use them as metadata to enhance how parsed types behave, but do not provide any functionality by themselves. Even though I use them heavily in Lighthouse, I do not believe it is useful to add them programmatically, instead some sort of structured metadata as proposed in #588 (comment) could be implemented.