Today we are releasing further improvements to the schema customization that we’ve released in version 2.2.0. You can use them with Gatsby 2.5.0.
It is now possible to indicate to Gatsby, that you want to add a resolver to an explicitly defined fields. Use extensions like
@dateformat to add default arguments or/and resolvers to fields. In addition, when
@dontInfer is set, Gatsby will no longer run inference for marked type, allowing one to improve performance for large data sets.
After about a month of testing schema customization both pre and post release, we determined a couple of issues. The original aim of our schema customisation work was to remove uncertainty in a user’s schemas when their data changes.
However, the original design allowed some uncertainties to still creep in. In addition, it made inference a heavier process, trading performance for consistency without providing a way to opt-out completely. To summarize, the schema customization work released in Gatsby 2.2.0 suffered from a few non-ideal issues:
- Resolvers and arguments of fields like Date and File was determined by inferred data
- There was no easy way to use arguments/resolvers to override the above
- Inference was run even when
@dontInferflag was on
- There was no way to control inference outside of SDL, e.g. in Type Builders
Therefore we are excited to announce some changes in how we perform inference. In addition, we are deprecating some of the features introduced in 2.2.0 and will remove them in Gatsby v3.
First of all, we are deprecating
noDefaultResolvers. It was an argument of
dontInfer. We feel it was confusing and in some cases it didn’t even actually add resolvers :). We will support
noDefaultResolvers until version 3, after which
@infer behavior (see below) will become a default and
noDefaultResolvers will be removed.
We didn’t want to break things, so we keep old default behavior, even though we think it’s not optimal. Add explicit
@infer and resolver extensions (like
@link) to fields to be future proof.
Applies with no
@infer and no
@dontInfer on a type. Equals to
Type gets all inferred fields added. If type has defined fields of types
File and any other node, and we inferred that they should have resolver options, resolver options will be added to type with a warning.
Type gets all inferred fields added. Existing fields won’t automatically get resolvers (use the provided resolver extensions).
Inference won’t run at all. Existing fields won’t automatically get resolvers (use resolver extensions).
Inference will run, but fields won’t be added. If a type has defined fields of types
File, and any other node, and we inferred that they should have resolvers/args. These will still be added in Gatsby v2, but we will now warn and note the deprecation.
Here are suggested changes to your code if you are using schema customization already. Your code will work in Gatsby 2.5.0, but those changes will ensure it stays compatible with Gatsby 3.0
- Add resolver directives to fields
@dontInferto your type if you don’t have it already
Add resolver and resolver options (such as arguments) to the given field. There are currently 3 extensions available.
@dateformat- add date formatting arguments. Accepts
localeoptions that sets the defaults for this field
@link- connect to a different Node. Arguments
from, which define which field to compare to on a remote node and which field to use on the source node
@fileByRelativePath- connect to a File node. Same arguments. The difference from link is that this normalizes the relative path to be relative from the path where source node is found.
proxy- in case the underlying node data contains field names with characters that are invalid in GraphQL,
proxyallows to explicitly proxy those properties to fields with valid field names. Takes a
You can now apply configuration to type builder types through an exposed
With these improvements we are confident that we’ve solved some pain points that people may have been experiencing with the schema customization API. We would love for feedback about these new features and schema customization, in general. Please post your thoughts to the schema customization umbrella issue if you encounter any problems or have any suggestions!
However, this is but a start and a path of continual, gradual improvement. We are continuously working on further improvements, like allowing users and plugins to define their own extensions (see PR #13738).