Confession: I don’t write a lot of tests for my frontend code. This isn’t something I talk about a lot because I’m scared of the pitchforks on the horizon.
I write React frontends with TypeScript. I don’t don’t write tests because I’m lazy, or because I don’t have time, I simply don’t see a lot of value in the amount of maintenance they require.
Gary Bernhardt wrote an article on how his apps are covered, and it hits the nail on the head.
We don’t want tests covering most of our React components, though. That wouldn’t help with the main difficulties in writing components:
We might pass props around incorrectly. TypeScript already solves this problem for us almost completely.
The components might use the API incorrectly. Again, we’ve solved this problem with TypeScript.
The components might look wrong when rendered. Tests are very bad at this. We don’t want to go down the esoteric and labor-intensive path of automated image capture and image diffing.
One thing I do write tests for is complex code that isn’t coupled to components, like reducers. And the nail gets hit again:
Although we don’t test components directly, there are some other parts of the frontend code that are tested directly. For example, we have some high-value tests around some React reducers because they’re tricky and full of conditionals.
Last year, I added webmentions to this blog. To recap, webmentions are a web standard to create a network of comments, likes, and reposts between ordinary sites. I set up a brid.gy account to poll Twitter for webmentions targetting my blog, and I caught them with webmention.io.
Webmentions were fetched with AJAX and rendered at the bottom of each page. There were two things I didn’t like about this approach:
I’d rather just have them prerendered by Hugo, my static site generator
Webmentions are stored on Webmention.io, but I’d rather have ownership over them
After some tinkering, I came up with an alternative: a cron-based GitHub Action that queries webmention.io for new webmentions. The Action then commits them to my site’s repository, so I can access the data with my static site generator, Hugo.
A short intro on my second series: Unix things I always forget!
An attempt to document the Unix commands I know and care about. Consider this series a living document that will grow organically; I won’t be updating or adding new posts on a set schedule.
When updating an underlying dependency, I don’t always tag a new major version. Some people consider this to be a breaking change, but it isn’t. Here’s how to deal with dependency and language updates from a package maintainer’s perspective.
Reviewing pull requests, I often see contributors sneakily adding editor configuration to the repository’s .gitignore file.
composer.lock
package.lock
+ .vscode
If everyone would commit their environment-specific .gitignore rules, we’d have a long list to maintain! My repository doesn’t care about your editor configuration.
There’s a better solution to this: a personal, global .gitignore file for all your repositories. Here’s how you can set one up.
I’ve always had a hard time finding a proper response to the classic “privacy isn’t important because I have nothing to hide” argument.
Paul Jarvis, cofounder of the privacy-first analytics tool Fathom Analytics, makes some strong points in But I have nothing to hide.
Whether it’s on reality TV or even just social media, we act and speak differently because we know we are being watched. We lose our ability to be authentic or explore our own identity and views because we’re stuck trying to put forward our “best selves” and ensure everyone else that we’re here “for the right reasons”.
I just upgraded Node.js on a Laravel Forge provisioned Ubuntu server for the umptieth time. I can never remember how to upgrade to a higher major Node.js version, so I’m documenting the process for future me.
On to our first component: a dropdown list. I’m going to walk through the implementation I landed on in a recent project. There are many ways to build dropdowns, and you might want to shape the API your way, so use this post as a source of inspiration.
I came across this post by Jason Fried (from Basecamp) about giving ideas a few minutes before shooting them down.
I’ve caught myself blurting out unnecessary negative opinions when presented with an idea. More often than not, I have more empathy towards the idea a few minutes later, and feel bad about my initial reaction.
Next time you hear something, or someone, talk about an idea, pitch an idea, or suggest an idea, give it five minutes. Think about it a little bit before pushing back, before saying it’s too hard or it’s too much work. Those things may be true, but there may be another truth in there too: It may be worth it.
In the previous posts, we’ve gone through our first few utility functions. We now have enough in our toolbox to move on to our first component. However, where do all these functions belong?
In Selecting elements (part 1) we learned how to select elements from the DOM, and how to find elements inside other elements, both with our own $ and $$ helpers.
In part 2, we’re going to review two DOM element instance methods: closest and matches.
Lets get warmed up! Before we can get productive, we need two small helpers that we’ll be using in most components we’ll build from here on. I’m talking about $ and $$, which are wrappers around document.querySelector and document.querySelectorAll.
JavaScript frameworks are great, but overused. Adding small bits of interactivity to an interface shouldn’t mean installing kilobytes of dependencies or introducing complex build tools.
It’s time for a diet. I’m challenging you to build something without a framework, or follow along and learn something along the way.