Custom type directives that mimic those such as @infer need an API like createFieldExtension

[pauleveritt]

Summary

It's easy to write and register a schema field directive with the createFieldExtension action. It doesn't appear that this action works for making a type directive such as the built-in @infer, which is called during startup and has access to schemaComposer.addDirective.

Note: I'm using directive instead of extension. Should I be saying "custom type extension"?

Basic example

I have a branch in a repo with a createSchemaCustomization function that attempts to add a metadata type directive. It would be used in a type definition such as Author here.

Some notes:

• I believe my use of locations is a decoy as createFieldExtension isn't setup to pass that along as the flag which tells schemaComposer.addDirective to do different behavior

Motivation

I want custom metadata about types and the GraphQL community has indicated that type directives are the way to do this. In this case, I want, for each type, the plural form to let me know what type to create in onCreateNode. If something is in /blogposts/ then I will create a BlogPost (incomplete implementation )

My alternative is to make people maintain two sources of content type definitions: one in GQL and one in regular JS objects.

[tbrannam]

@stefanprobst amazingly very much in the same vain as my question

[tbrannam]

My ask is very similar - with the assumption that the resolvers for these may be passed to Apollo-Link chain to be processed.

[pauleveritt]

@tbrannam I suspect something like this might be deep enough that it takes a while. As a workaround, I plan to make a field directive metadata that does the same thing, with a default value so it doesn't have to be entered in instances (documents) of that type.

Sort of like the [example about drafts)(https://www.bradmcgonigle.com/blog/drafts-for-gatsby).

I'm hoping that I can introspect all the types, look for this special field, grab the directive, and see its arguments.

[pauleveritt]

@tbrannam I struck out...adding a metadata field with a directive to add type metadata didn't work. That information isn't available via queries on the type, e.g. {__type(name: "Author"} {fields: {name}}}

I can get lots of information on the field, but not the directive. Which means I'd need to query an actual document, which defeats the point of introspection.

I'll have to move type metadata out of the type system until Gatsby lets me access schemaComposer to write type directives.

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[vladar]

I guess my main question is how do you plan to utilize this metadata? It will be available in custom GraphQL resolvers but not in the APIs.

For example, your @metadata(plural: "Authors") won't be available in onCreateNode because node sourcing step occurs before schema building (so GraphQL types with this metadata are not constructed yet).

One option to make this metadata more available is to build an intermediate schema (entirely based on type definitions, without inferring). But I think we should collect more usage scenarios to address this properly.

[pauleveritt]

@vladar Thanks for the response. I come from a CMS background and I want to make a plugin that can be used as a lightweight, Markdown-based CMS.

Currently I spread information about content types in different places: .graphql files, configuration knobs, etc. I'm hoping to have a single source of truth, and the types is a natural place.

This extra metadata would be used in default menus, listings, finding template files, etc.

[pauleveritt]

That's an interesting (and deal-breaking) point about onCreateNode. I suspect with that in mind, it's most likely to just close this issue.