100 Days of Gatsby

By Paul on January 30, 2020

Welcome to the new Bold Oak Design blog! Since I’ve been digging a lot more into Gatsby lately, I figured I’d document the learning process a bit here. In line with this is Gatsby’s own 100 Days of Gatsby challenge, so add this one to the pile. 🙂

Bold Oak Design is hosted on Netlify and sourced from a private repository on GitHub. It started life as a completely static index page, but I’ve slowly progressed outward from there as I’ve learned how to use GraphQL queries. As it stands right now, there are two sources for non-static content. One is the list of projects I’ve worked on, which can be found on the Work page.

As an aside, I’m really not sure what I should include there, or in how much detail. Some of the work I’ve done consists of client work, like for nonprofit organizations WASA and iSACRA. Some of it has been for personal projects and made publicly available, like my WordPress themes. For now, I guess I’ll leave it as it is.

The other content source is the list of blog posts. Well, does one post make a list? There will be more, at any rate. It’s the more complex of the two sources, since unlike the work list, each blog post also requires its own page. I’ll get to that in a moment.

In the case of both the work and the blog posts, each entry has its own Markdown file. The paths are unique for each type, so the GraphQL queries defined on the Work and Blog pages can find build the lists separately using the filter parameter. So using a single content folder at the root, each content type is located in its own subfolder, like content/blog and content/work.

Using this setup, the gatsby-config.js file only needs to look in a single location for both (or all, if I end up making more) content:

module.exports = {
	// ...
	plugins: [
			resolve: `gatsby-source-filesystem`,
			options: {
				name: `content`,
				path: `${__dirname}/content`
		// ...

Finally, the Blog and Work pages each use the filter parameter in their GraphQL queries to narrow down the correct source.

query {
			filter: { fileAbsolutePath: {regex : "\/blog/"} }
			sort: { fields: [frontmatter___date], order: DESC }
		) {

For the Work page, that’s all that’s required. Each work is displayed on the one page, which iterates over each item and displays them using a custom React component. The blog posts are more complicated. It’s not enough to display them in a list; they each need a unique page, and that’s where the gatsby-node.js file comes in. Combined with the gatsby-source-filesystem plugin, it uses a template file in conjunction with a GraphQL query (again, using the filter to narrow down the blog posts) to generate the necessary pages.

While I’m on the topic of the blog posts, I’m not using any sort of CMS to manage them. I know of some options like Netlify CMS (not to be confused with plain ol’ Netlify, which I’m using to serve the static files) and TinaCMS (which has the best name ever for several reasons), but at this juncture I feel there’s little point. The posts are kept in Markdown files right in the same repo as the rest of the site. Since it’s just me making the posts, I don’t need to put a visual layer over the top. I’m comfortable enough writing in Markdown (or the occasional HTML). If I see a need for it — or I just decide to because why not — I may build in support for MDX, but for now I don’t see the need to include any React components in my posts. That may change, you never know.

© Copyright 2020 - Bold Oak Design LLC