InuitCSS and Gatsby - My First Plugin
So efforts to consolidate and focus development efforts towards greater productivity are welcome, in a world where the tooling is for me a barrier to learning and often creativity.
The Great Gatsby
In hindsight, there are many websites that I built in Rails, backed by a SQL database, that could and should have been built using the approach espoused by Gatsby (Middleman in Ruby was an excellent solution I thought). Why have live calls to a database to generate content over and over, if that content doesn't change often? Better to render it in advance and serve the static file straight out of a CDN. Simple, effective and fast.
Gatsby's approach makes building a modern, single page application seem straightforward. But what about when you need features beyond the core functionality? It's rich plugin system provides plenty of ready-made libraries take take the pain out of the day to day of building your site.
When I tried to incorporate Inuit into my Gatsby project, I found that it wasn't entirely straightforward. There were a couple of manual steps, which I knew I'd forget if I ran them infrequently, once per project. So I thought this would be a good excuse to learn how the plugin system worked.
My first Gatsby Plugin
Gatsby provides for extensions of the core framework through a plugin mechanism. A plugin is essentially just an Node.js package, with some Gatsby conventions. Developers can access the Gatsby API, to hook into various lifecycle points during the build process, for instance pulling data from somewhere and dynamically creating pages from it. In my case, the plugin is relatively modest; it doesn't create any Redux state. Essentially, it is just moving files into place, and ensuring that the SASS is being loaded correctly.
Using a yarn monorepo, development is smooth, using a template gatsby project to test drive the plugin, which also serves as live documentation on how to use it. I needed to access a hook
onPreInit, which runs upon the initialisation of the gatsby dev server or build process.
I then use a little trick to dynamically find the path to the inuitcss node module, using
require.resolve('inuitcss'). This returns the path to where yarn installed the module, rather than making assumptions about relative paths if the end user installed their module elsewhere. I then extract the manifest files that inuit css uses to configure the framework, allowing the end Gatsby developer to start writing SCSS.
After that, to publish a plugin was a simple step of writing a README and publishing an npm package. By adding some keywords to the package.json, I was impressed to see the plugin magically appeared on the Gatsby plugin library later that day.
Don't drop your CSS right inuit (...sorry)
So the next time you're tempted to use styled components, why not consider keeping your SASS/CSS separate, and focus on object-orientated, reusable, readable and extensible CSS, and regain control of your frontend development! And do it in Gatsby!