Getting started with GatsbyJS and WordPress

Earlier this week I began rebuilding my blog using GatsbyJS + WordPress. As I familiarized with Gatsby, I found myself flipping through a million tabs, and I thought it might be useful to summarize concepts and to aggregate links I found helpful.

I recently decided to tackle a redo of my blog. I wanted to do something different and I’ve been hearing a lot about GatsbyJS. A static site generator for React that I can pull my existing WordPress data for? Sold. I’ll try it.

The documentation is a little scattered — I started by reading the tutorial and quickly veered off. I generated a new site using the default starter and read through what it gave me. Assuming you have the Gatsby CLI installed, run:

gatsby new gatsby-example-site

That gets us a new site directory with a couple (mostly) empty “gatsby”-prefixed files and a src directory with some basic scaffolding. The configuration and lifecycle hooks for Gatsby get put in those “gatsby”-prefixed files, gatsby-config.js, gatsby-node.js and gatsby-browser.js.

gatsby-config.js

Essentially the Gatsby home base. The two main things defined here initially are siteMetadata and plugins.

module.exports = {
  siteMetadata: {
    title: 'Gatsby Default Starter',
  },
  plugins: ['gatsby-plugin-react-helmet'],
};

gatsby-plugin-react-helmet is just a plugin the starter includes. It’s a document head manager for React.

Also, there isn’t currently documentation on arguments for gatsby-config, but you can get an idea here if you’re (also) curious.

gatsby-node.js

We can make use of any of Gatsby’s node APIs by exporting a function with the name of that API from this file.

For my purposes, the only one I had to interact with so far was the createPages API. This gets called after our data has been fetched and is available to use to dynamically build out our static pages. More on this later.

gatsby-browser.js

Same as above, we can make use of any of Gatsby’s browser APIs by exporting them from this file.

I haven’t needed to make use of any of these yet, but they provide a hook into client runtime operations — for example, replacing the router component, as seen in this example.

Plugin: gatsby-source-wordpress

My natural next step is getting my data successfully pulling from WordPress. There’s a plugin for that. gatsby-source-wordpress is Gatsby’s plugin for sourcing data from WordPress sites using the WordPress JSON REST API.

(Fun fact: the WordPress REST API is already included starting with WordPress 4.7 — no longer requires installing a WordPress plugin. I didn’t actually know that, not having used the WordPress REST API for anything before).

I started by reviewing the code for the demo site for using the plugin.

Configure the plugin to pull your data

In gatsby-config.js, add your configuration options, including your WordPress site’s baseUrl, protocol, whether it’s hosted on wordpress.com or self-hosted, and whether it makes use of the Advanced Custom Fields (ACF) plugin.

module.exports = {
  ...
  plugins: [
    ...,
    {
      resolve: `gatsby-source-wordpress`,
      options: {
        // your wordpress source
        baseUrl: `amberley.me`,
        protocol: `https`,
        // is it hosted on wordpress.com,
        // or self-hosted?
        hostingWPCOM: false,
        // does your site use the Advanced 
        // Custom Fields Plugin?
        useACF: false
      }
    },
  ]
}

Use the data to dynamically construct pages.

Once your source plugin is pulling data, you can construct your site pages by implementing the createPages API in gatsby-node.js. When this is called, your data has already been fetched and is available to query with GraphQL. Gatsby uses GraphQL at build time; Your source plugin (in this case, gatsby-source-wordpress) fetches your data, and Gatsby uses that data to “automatically infer a GraphQL schema” that you can query against.

The createPages API exposes the graphQL function:

The GraphQL function allows us to run arbitrary queries against the local WordPress GraphQL schema… like the site has a built-in database constructed from the fetched data that you can run queries against. (Source)

I used the gatsby-node.js file from the demo to get started. For my purposes the ‘posts’ code does what I need it to do out of the box (at least for the moment) . It queries our local WordPress GraphQL schema for post data, then iterates through each post node to construct a static page for each, based on whatever template we define and feed it.

For example, below is the part of the demo gatsby-node.js file that iterates over all the WordPress post data (annotations mine).

const postTemplate = path.resolve(`./src/templates/post.js`)

_.each(result.data.allWordpressPost.edges, edge => {
  createPage({
    // will be the url for the page
    path: edge.node.slug,
    // specify the component template
    // of your choice
    component: slash(postTemplate),
    // In the ^template's GraphQL query, 'id'
    // will be available as a GraphQL variable
    // to query for this posts's data.
    context: {
        id: edge.node.id,
    }
  })
})

The documentation defines a Gatsby page as “a site page with a pathname, a template component, and optional graphql query and layout component.” See the docs on the createPage bound action creator and guide on creating and modifying pages for more detail.

… Take a step back to “templates”.

In the step above we dynamically create pages based on our data by passing the absolute path to a defined template to “component”. So what’s a template? Basically a page component we define and feed into the loop described above. We pass the post id to “context” to make it available as a graphQL variable in the template file. The graphQL query defined for the template then uses that id to query for data specific to that post.

… Take another step back to “pages”.

So a template is a just page component that we can use to programmatically create pages. Then what’s a page component?

Page Component — React.js component that renders a page and can optionally specify a layout component and a graphql query. (Source).

React components living in src/pages automatically become pages . The file name of a page maps to its site path. My site in its current state only has one good example of this — src/pages/index.js maps to amberley.blog. If I had an ‘about’ page, it would live at src/pages/about.js , and map to amberley.blog/about. (Since that doesn’t exist, it will actually end up hitting the only other page currently defined in my site, which is src/pages/404.js — (read about 404 pages).

If you include the “optional graphQL query” noted above, the result of that query is automatically passed to the component on a data prop (this.props.data). (Read more on graphQL queries).

Onward

While this isn’t a step-by-step tutorial, more a guided walkthrough of me walking through an initial Gatsby setup, if you’re following along with the demo code you’re probably close to (or already!) seeing your WordPress data populate your Gatsby dev site if you run gatsby develop!

Sidenotes

  1. You don’t need to know graphQL to get started with Gatsby. I didn’t. It’s been a good introduction.
  2. Gatsby makes heavy use of plugins — both official and community — for a lot of things, from one that implements Google Analytics, to one that adds GitHub’s accessibility error scanner to all pages.
  3. Read through some of the source code. I particularly enjoyed reading through the bootstrap process. (It’s beautifully commented).
  4. Gatsby.js is a static Progressive Web App (PWA) generator, but to be PWA friendly (at least according to the Lighthouse PWA audit), look into two plugins: gatsby-plugin-manifest and gatsby-plugin-offline.
  5. I did end up deploying with Netlify, and I’m super happy with it.
  6. Figuring out how to get GitHub gists to embed correctly is now on my list 🙂

Resources (aside from those linked throughout)

  1. Rebuilding my portfolio website with the great GatsbyJS and WordPress
  2. Migrating to GatsbyJS Part 1
  3. Experimenting with GatsbyJS and the WordPress.com API
  4. The Web App Manifest | Web Fundamentals
  5. App Manifest Generator

The Road So Far Pt III

Exactly a year ago I posted The Road So Far Pt II. I now have two full years under my belt since undertaking this career pivot. I’m still not sure what I want these recaps to be, but I feel compelled to keep going now that it’s a pattern.

2017. 2017 was a “growth year”. I always laugh at that phrasing (because which year isn’t) but while it wasn’t the greatest year, I learned quite a lot.

Continue reading The Road So Far Pt III

The Road So Far Pt II

Almost exactly a year ago, I first started writing about my pivot to working full-time as a web developer (aka The Road So Far Pt I). tldr; after dancing around the edges of embracing this career (in every possible way, for my whole professional life leading up to that point), it had become clear I wanted and needed to commit. I find that reflection is the only way to take stock of progress, and a year seems like a good time to look back.
Continue reading The Road So Far Pt II

The Year of the Blanket

I love blankets (in general, and to knit!) Big, squishy, comfy, cuddly blankets– likely, at least in part, due to my conflicting relationship with actually paying attention to gauge. It doesn’t matter as much if it’s off by a bit — it’s a bit like cooking vs. baking. Anyway, onto the assortment of blankets from this year:

Continue reading The Year of the Blanket

Event Roundup: Emberitas and Front Porch

Finally, finally, I have time to hit up local events and meetups again, and Austin has not disappointed. (See what I was up to the first half of the 2016.)

#Emberitas

First up, Emberitas. I found out about this event through the Women Who Code – Austin network. Three awesome women in the Austin Ember community decided to organize this free one-day workshop to introduce women to Ember.js. (All bootcamp grads, by the way — two from MakerSquare and one from CodeUp).

Continue reading Event Roundup: Emberitas and Front Porch

Async patterns: Promises

Given our understanding of what async is, how the callback pattern manages async, and some of the deficiencies of the callback pattern, let’s dive into another, newer pattern — promises.

Promises are clearly exciting the JS community. As someone who never really knew JavaScript before promises, I have only an academic understanding of the magnitude of this shift. In fact, I think I was exposed to management of async first with callbacks to make promises seem just that much more awesome (like building a node server before meeting Express). Understanding both is important to a deeper understanding of each, individually.

As with callbacks, for a new developer, it can be difficult to sift through the massive amount of information available online. For the benefit of anyone else newly exposed to promises, in this post I’ve attempted to cull the resources and posts that I have found most enlightening through my own learning.

Continue reading Async patterns: Promises

Async patterns: Callbacks

So what is a callback function?

A callback function, also known as a higher-order function, is a function that is passed to another function (let’s call this other function “otherFunction”) as a parameter, and the callback function is called (or executed) inside the otherFunction. A callback function is essentially a pattern (an established solution to a common problem), and therefore, the use of a callback function is also known as a callback pattern. (Source)

Continue reading Async patterns: Callbacks

What is asynchronous JavaScript?

When people talk about asynchrony in JavaScript, what do they mean? First, a real-world example of an asynchronous process (summarized here, and originally here).

Imagine you walk into a coffee shop to get a latte. If they’re busy, perhaps you wait in line. When it’s your turn, you place your order with the cashier, and pay for the drink. The cashier writes your order — maybe even your name — on a coffee cup, and places it behind the empty (not yet fulfilled) cup of the person who ordered before you. Perhaps the shop is quite busy and there are ten cups ahead of yours. That queue of yet-unfilled coffee cups allows for the separation of the cashier (processing and queuing orders) and the barista (fulfilling orders based on the information supplied by the cashier). This queuing process results in increased efficiency and output. (The original source expands on the metaphor and is quite interesting). This is an example of asynchronous, non-blocking behavior.

Continue reading What is asynchronous JavaScript?