Gatsby and Contributing to Open Source

I have been using Gatsby since July of 2016. That is v0.12.0 for those keeping track. Does this make my hipster? shrug Anyways, the journey had me coming from Knockoutjs. I was working out of flask (the python webserver), and really wishing I could do more with my frontend. Getting into D3js, it required some effort to shoehorn it into Knockoutjs. After seeing a presentation on isomorphic/universal reactjs, the bug had finally bit me hard enough.

My foray into reactjs was still during the days of boilerplates. I busted my knuckles on a couple boilerplates, and finally settled on one. I made a small app using some more progressive D3js patterns within React. The patterns are pretty typical and kind of old hat now, haha. I was loving it. A local developer consulting company called Rokkinkat puts on a quarterly hack-a-thon called, Hack ‘n Tell, which I pretty regularily attend. At one of these, I decided to redo my personal website and try out Gatsbyjs. I know I enjoyed programming with Reactjs, and Gatsbyjs seemed to be a great fit for a personal website. I didn’t want to deal with a webpack config, but I wanted that react power to enable writing articles containing calculators and D3js. (This is before code repls were a thing as well!). I had been eyeing up Gatsbyjs for a handful of months, and now I had a purposeful use case. This brings us to July 2016.

I used v0.12.X for a handful of months, but this was right around when alphas started coming out for v1. I slowly got involved in v1 and eventually started trying to run my personal website on the new version. Well, I have a Windows machine at home. With my background in Structural Engineering, 99% of the computing in the industry is on Windows machines. That is the exact opposite demographic for programmers, it seems. Most of my early effort was in better support for Windows. Eventually we abstracted out the problem peices, wrote tests and setup a Windows based CI, Appveyor. This meant we would expose issues as they were committed instead of days later by someone new to the code.

The next step was bringing better support to JavaScript based files. To carry over functionality I had added in v0, I wrote gatsby-transformer-javascript-static-exports which I eventually replaced with gatsby-transformer-javascript-frontmatter to better align with the ecosystem. It allows functionality very similar to markdown style frontmatter, which is especially useful when creating JavaScript based articles or posts. (Remember that obsession with d3js?) With this I started work on the example to highlight writing blog posts in written in JavaScript. A few more Appveyor tweaks, and we were off to the races.

From there, most of my effort ended up being experimental. We had layouts as a carry over functionality from v0. The JavaScript files still didn’t have a great way to compose layouts around it. So I worked with another contributor and we added multiple layouts. After that, I experimented with nested layouts. I was able to add the functionality, but the overhead and complexity was just too great. We ended up just pushing fragments and higher order components as the best solutions. And even more, I eventually recommended killing layouts completely.

With the surface area of gatsby much more slimmed down (at this point, just in theory), I felt this really opens the door for a component based theme system. I removed layouts from my personal site, and started experimenting with a theme system, gatsby-theme-bulma, gatsby-theme-bulma-layout, and gatsby-theme-bulma-blog. There is possibility here, but it will need to wait until v2 lands with some special support. We need to babel components, but we cannot do it ourselves because it changes the graphql queries that Gatsby needs to extract. We need Gatsby to extract the queries first, and then babel the components for us. (Babel transpiles your code from newer features to older features for better browser support.)

In the interim, I decided to update my personal website (to what you see now). I went to add a couple source plugins, and found them missing features I would love. It appears that it is just lack of understanding how to best put them together. So I decided to create gatsby-source-airtable-linked. I am using it to put our recipes on this site (from recipes.amyandjacob.com), but it also serves as a great example on the finer points of gatsby-source-* creation. Another blog post incoming on this topic!

Now that you are caught up, I want to say I love working with Gatsby. Contributing can be a lot of effort, and that work doesn’t always make it into production. There is value though in prototyping the paths not to follow. It is great to see and be a part of a project that evolves over time like this one. I recommend contributing, even if it is just in the documentation.