Heads up! After using this, I have found myself needing to run `gatsby clean` before `develop` or `build` when using this approach.

Well. I had a great idea to use Gatsby's StaticQuery component for catalogs and product displays. I was hoping to also use the useStaticQuery hook for experimenting with shadowing. There is just one problem.

Even though Gatsby is a static site generator, it can be used to build dynamic applications. Gatsby is, after all, just a framework for building a React application. It just happens to be extremely opinionated and generates an artifact that is a static site. To me, "dynamic" means that an application maintains some form of state.

At the beginning of December, Ondřej Mirtes released PHPStan 0.12! 0.12 brought about many changes. However, 🙃, it broke the PHPStan Drupal extension.

While fiddling with Gatsby, I wondered: what about fetching data from Drupal to push into the siteMetadata array? In the gatsby-config.js API file, you can specify metadata about the site.

I just discovered that there are some problems when working with the gatsby-source-drupal plugin. There is already a problem where empty data doesn't generate the schema type (even if it has no fields.) There is another one if you only receive one value.

As I continue working on a Drupal Commerce demo with GatsbyJS, I have moved on towards using GatsbyJS themes. GatsbyJS themes are composable, meaning you can use more than one within a single GatsbyJS application. However, it seems like you really piece together different themes to build out sections of your site.

I finally have my workspace set up, allowing me to begin serving content from one Drupal Commerce API server to three GatsbyJS apps.

Yesterday I made an attempt to use a single GatsbyJS instance to create multiple build outputs. That didn't work out so well. I also realized I was trying to fit a square peg through a round hole. Why fight how GatsbyJS works?