Category: Uncategorized

GraphQL fields can handle scalar values—namely String, Date, ID, Int, Float, Boolean, and JSON—but fields can also contain complex values in the form of objects. To handle these nested fields, we need to provide an explicit type definition for the nested type. For instance, we may wish to ensure that each MarkdownRemark (Markdown document) Node contains a frontmatter field known as frontmatter​.transla⁠tions that itself is a list of strings: Note that because we…

For this reason, it can often be preferable to create type definitions manually, explicitly defining types so that Gatsby can validate the field and inform you if there is malformed data, such as an invalid Date. Through the createSchemaCustomization Node API, Gatsby provides a means for developers to supply the GraphQL schema with explicit type definitions in gatsby-node.js using the createTypes action, which…

In Gatsby’s GraphQL schema, these three data types (MarkdownRemark, AuthorJson, and TranslatorJson) are each represented using the Node interface, which defines the GraphQL fields mutually shared by Node objects that are generated by source and transformer plugins (namely id, parent, children, and several internal fields such as type). Written in GraphQL’s Schema Definition Language (SDL), the Node interface is defined as follows: The types that are created by source…

In many Gatsby sites, we need to merge data from disparate sources and schemas into a synthesized GraphQL API that can be consumed from any Gatsby component. Standardizing discrete formats into a single schema supports long-term maintenance and a more efficient developer experience. Schema customization allows us to combine distinct data types into a cohesive schema—in…

During the build lifecycle, which we cover in detail in the final section of this app, Gatsby generates a GraphQL schema that enables Gatsby developers to query data from a variety of external or internal sources. This step takes place automatically during the Gatsby bootstrap. However, there are often scenarios where some schema customization is required…

It’s possible to substitute each HTML element that MDX renders with a custom implementation as an alternative. This enables Gatsby developers to leverage a set of design system (collections of repeatable design patterns in code) components when rendering MDX files. For example, the following layout component substitutes certain elements, like <h1>, with React components that we’ve defined.…

As we saw previously, we can import arbitrary React components into our Markdown documents, such as the Figure component we wrote earlier in this section: Components used in MDX files can also be universally leveraged across a Gatsby site as shortcodes, thanks to the MDXProvider component. To make the Figure component available to all your MDX files, for instance, you could add the following…

Once you have gatsby-plugin-mdx available, either through Gatsby’s own MDX starter or by installing it into an existing Gatsby site, any MDX files located within Gatsby’s src/pages directory will automatically be converted into pages. For instance, if you create a page src/pages/about.mdx, Gatsby renders it at my-site.com/about. You can use frontmatter in Markdown to define certain fields that will be available in…

Consider the following example Markdown document (say, src/blog/blog-post.md): We can write a Figure component based on this in JSX, such as the following: Now, we can insert this Figure component into the same Markdown document, src/blog/blog-post.md, using MDX: The Gatsby ecosystem makes available a starter, gatsby-starter-mdx-basic, to add MDX support instantly to a new Gatsby site. To spin up a new Gatsby site using…

In the previous section, we saw that Gatsby recipes are written with JSX elements interpolated into Markdown files. But what are these elements, and how is it possible to write JSX elements directly within Markdown? The answer lies in MDX. MDX is an extension to the Markdown format that allows Markdown and JSX users to interpolate…