Category: 14. Gatsby Internals

  • The async-requires.js file

    Like sync-requires.js, async-requires.js is dynamically created by Gatsby, but its motivation differs in that it is intended to be leveraged for code splitting by Webpack. Instead of utilizing require to include components by path, this file employs the import keyword together with webpackChunkName hints to connect the dots between a given listed componentChunkName and the resulting file. Because components is a function, it can be lazily initialized. The async-requires.js file also…

  • The sync-requires.js file

    The sync-requires.js file is a dynamically created JavaScript file that exports individual Gatsby components, generated by iterating over the Redux components namespace. In these exports, the keys represent the componentChunk name (e.g., component—src-blog-2-js), and values represent expressions requiring the component (e.g., require(“/home/site/src/blog/2.js”)), to yield a result like the following: This file is employed during the execution of static-entry.js to map each component’s componentChunkName to its respective component implementation.…

  • The pages.json file

    The pages.json file represents a list of Page objects that are generated from the Redux pages namespace, accounting for the componentChunkName, jsonName, path, and matchPath for each respective Page object. These Page objects are ordered such that those pages having a matchPath precede those that lack one, in order to support the work of cache-dir/find-page.js in selecting pages based on regular expressions prior to attempting explicit paths. Example output for a given Page object appears as follows:…

  • Writing Out Pages

    Among the final bootstrap phases before Gatsby hands off the site to Webpack for bundling and code optimization is the process of writing out pages. Because Webpack has no awareness of Gatsby source code or Redux stores and operates on only files in Gatsby’s .cache directory, Gatsby needs to create JavaScript files for behavior and JSON files for…

  • Query execution

    The second step in the query extraction and execution process is the actual execution of the queries to enable data delivery. In the Gatsby bootstrap, queries are executed by Gatsby invoking the createQueryRunningActivity function in src/query/index.js. The other two files involved in the query execution process are queue.ts and query-runner.ts, both located in the same Gatsby source directory. TIP For a diagram illustrating the…

  • Query extraction

    The first step in the process is query extraction, which involves the extraction and validation of all GraphQL queries found in Gatsby pages, components, and templates. At this point in the build process, Gatsby has finished creating all the nodes in the associated Redux namespace, inferred a schema from those nodes, and completed page creation. Next,…

  • Query Extraction and Execution

    After the createPages API executes, the next step in the Gatsby build lifecycle is for Gatsby to extract and execute the queries that declare data requirements for each page and component present in the Gatsby files. In Gatsby, GraphQL queries are defined as tagged graphql expressions. These expressions can be: Exported in page files Utilized in the context of the StaticQuery component…

  • Page Creation

    Once schema generation is complete, including schema inference and the provision of all schema root fields, utility types, and query filters, the next step in the Gatsby build lifecycle is page creation, which is conducted by invoking the createPage action. There are three primary side effects in Gatsby when a page is created. First, the pages namespace, which is a map…

  • Sort types

    For sort operations, given a field, GraphQL creates an enum of all fields (which accounts for up to three levels of nested fields) for a particular type, such as the following: This field is then combined with another enum containing an order (ASC for ascending or DESC for descending) into a sort input type:

  • Filter types

    For each Node type, a filter input type is created in GraphQL. Gatsby provides prefabricated “operator types” for each scalar (e.g., StringQueryOperatorType) that carry keys as possible operators (such as eq and ne) and values as appropriate values for them. Thereafter, Gatsby inspects each field in the type and runs approximately the following algorithm: If the field is a scalar: Retrieve a corresponding…