My Blog

Category: 13. Advanced Topics In Gatsby

  • Customizing html.js

    Gatsby uses a React component to render <head>, <footer>, and other elements that lie outside the core application destined for the browser. For the vast majority of Gatsby sites, the html.js file that comes packaged with Gatsby suits most requirements, but some situations call for additional customization. To customize your site’s default html.js, execute the following in the root of your…

  • Webpack

    As a Gatsby developer, you should attempt a custom Webpack configuration only if the default Webpack configuration built into Gatsby does not support your requirements and there is no Gatsby plugin available in the ecosystem that meets your needs. For those cases, Gatsby provides a Node API known as onCreateWebpackConfig that can be implemented in gatsby-node.js to adjust the default Gatsby Webpack configuration. When…

  • Babel Plugin Macros

    Gatsby also permits the use of Babel macros to apply compile-time code transformations that can be more flexible than Babel plugins. Rather than including them in the .babelrc configuration file, we insert Babel plugin macros into the working code of the files we write. Babel macros have two key advantages: There is no uncertainty about where particular nonstandard or noncompliant…

  • Babel

    Gatsby leverages Babel to provide support for both older browsers and modern JavaScript development paradigms. By default, Gatsby’s Babel configuration guarantees support for the previous two versions of commonly used browsers, Internet Explorer 9+, and any other browser having more than 1% market share. Babel in Gatsby automatically transpiles all JavaScript to ensure that all written…

  • Custom Gatsby Configuration

    Over the course of developing a Gatsby site, sometimes additional customization is needed to suit particular needs when it comes to how Gatsby performs a build and yields bundles for consumption. In this section, we examine custom approaches to Gatsby configuration outside of schema customization—we’ll look at using Babel, Webpack, Gatsby’s html.js file, and ESLint, as well as…

  • Creating Custom Interfaces and Unions

    One final common use case for schema customization in Gatsby involves creating custom interfaces and unions across multiple types through GraphQL’s abstract types. For instance, we could issue two queries for allAuthorJson and allTranslatorJson and then merge these by writing Gatsby code, but GraphQL can give us these types out of the box as a merged list. Because both the AuthorJson and TranslatorJson types…

  • Implementing the createResolvers API

    In the course of schema customization, sometimes type definitions are insufficient for requirements in Gatsby sites. For example, the GraphQL SDL and Gatsby Type Builders can handle the vast majority of use cases when it comes to adding type definitions, but more granularity is occasionally necessary in the form of custom resolvers, which allow us to…

  • Handling nested types

    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…

  • Creating explicit type definitions

    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…

  • The Node interface and automatic type inference

    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…