Halvor William Sanden

Craft CMS, React, TypeScript and useful overkill

This site's setup is was unnecessarily complex. It runs on the PHP based Craft CMS outputting JSON through its Element API, that is fetched and displayed using React written with TypeScript compiled to JavaScript. And that's only the front page, the articles still use Twig templating, the default for Craft.

The workflow isn't inefficient, but I could have made it simpler by just keeping Twig or making static pages. The pages would have loaded even faster too, a benefit for the users. But the nice thing with sites like this, is the room for experimentation and learning. And I think that justifies overkill setups.

Besides, there's always the opportunity to learn how to make the different parts of the overkill setup more efficient on their own and together.

Process is learning #

Whenever I want to learn something, I find it best to make, build and produce something. Talks and exercises don't always feel relevant, and I rarely find any motivation to improve on such work. Using my site as a playground forces me to make something that has to work.

I started 2015, wanting to learn how to use Craft CMS and Twig. I made a single page site that featured all the entries, mostly portfolio pieces at the time.

A couple of years later I started to learn React. I got the Webpack setup working, but I didn't know exactly how at the time. And there was just a small section of the site that used React, since I hadn't figured out how to combine it with Twig.

You can't put Twig syntax into React, so the content output need to be in JSON format. I set up that in 2018, joing three Craft-based sites into one multi-site instance and diving into its Element API. In short, it's a PHP file that is set to query only the information you need and generate JSON files based on that. It eliminates a few roundtrips to the database for every entry. I fetched it into React without any extra node modules – I try to avoid them if there is a reasonable way to do without.

I also took the time to understand what the different parts of my Webpack config was doing, which means I can add and remove settings as needed without being afraid that it should fall apart. I find knowing enough Webpack (or whatever you prefer) to keep the config small is more efficient than most zero-config solutions. I want to write and control most of the code I use, and for live projects, that is the only way.

In 2019 I refactored the site to use React Hooks. I wrote smaller components and implemented lazy loading for faster useful rendering. The last thing I did was to convert the project to TypeScript. It was the first time I used it in one of my own projects, and I chose to start by doing, rather than reading. That way, I can go back and improve when I've read up on it, instead of trying to learn everything or become good enough first.

I also went from detail heavy media queries, over to intrinsic grid based CSS, because screen resolution doesn't really matter anymore. And I ditched the notion that things have to look similar in IE, it just need to work.


This is how I learn. By making things, over and over again. Going back and forth between projects, problems, articles and solutions. Improving what I've done.