by sebastian de deyne
Web browsers have a few functions that accept callback parameters. setTimeout and requestAnimationFrame are the first that come to mind.
If you need to do multiple calls to these functions in a row, you quickly end up in callback hell. Here’s a quick tip to flatten your code with async/await.
Now that we’ve built a dropdown list, lets add some transitions to create open & close animations.
I occasionally send out a dispatch with personal stories, things I'm working on, and interesting links I come across.
Every now and then I do a quick checkup of a project’s npm dependencies. I like to keep them up to date by often doing small upgrades. It’s a lot less painful than doing large upgrades once a year.
One annoying part of this process is ensuring every dependency is on the latest major version. For example, if a project requires lint-staged@^8.0.0, yarn upgrade won’t upgrade it to lint-staged@^9.0.0 (luckily of course, it’s the behaviour I want during everyday development).
Today I learned about yarn upgrade --latest, which will upgrade all dependencies to the highest available version, despite the version constraints in your package.json file. lint-staged@^8.0.0 would happily upgrade to lint-staged@^9.0.0, even if it breaks semver boundaries.
Today I set up a static documentation site (built with Hugo) for internal use. Since it contains sensitive information, I wanted to add some sort of password protection.
We don’t need any dynamic user management for this, so I decided to store an encrypted password on the server with htpasswd and enable basic authentication with nginx.
Here’s how I set up basic HTTP authentication on a Laravel Forge provisioned Ubuntu server.
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.
Read on Are Tests Necessary in TypeScript? executeprogram.com.
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:
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.
A listing of my favorite ls features.
Every now and then I need to bump a dependency in a package, or require a higher PHP version.
{
"name": "my/package",
"require": {
- "php": ">=7.2.0",
+ "php": ">=7.4.0",
- "league/commonmark": "^0.19",
+ "league/commonmark": "^1.0",
}
}
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.
12 Mar 2020 via pjrvs.com
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”.
Read the full article on pjrvs.com.
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.
Read Give it five minutes on signalvnoise.com.
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?