In any modern browser's element inspector, you can force an element into a :hover or :focus state to debug styling issues. Sometimes, you want to debug an issue of an element in focus with a state controlled by JavaScript. Unfortunately, the forced states from the developer console aren't always enough. (Edit: unless you use Chrome apparently, scroll to the end for an alternative solution!)

I came across this problem when I was styling a custom <select> component in React. The dropdown menu is only visible when the input is focussed, but I couldn't inspect this state with the devtools. Whenever I wanted to browse the element tree, the devtools became the active element on the page and the menu disappeared.

Luckily, I came across a tiny snippet to help debug in this situation.

window.setTimeout(() => { debugger; }, 5000);

This will wait five seconds until it halts all code execution with a debugger breakpoint. With this snippet, I load the page, set everything up into the state I want to inspect—5 seconds is more than enough time—and wait for the timeout to fire. When the debugger is triggered, I can browse and tinker with the element tree without worrying about the page updating.

In React, I wrapped this in a useEffect call to run once for the component I wanted to debug.

useEffect(() => {
  window.setTimeout(() => { debugger; }, 5000);
}, []);

---

After I shared this post on Twitter, Bram tweeted that Chrome DevTools have a feature to circumvent this problem. With the "Emulate a focussed page" setting, the web page will remain in a focussed state when you're playing around in DevTools. Read more in the Chrome DevTool release notes.

I'm in the process of cleaning up some npm packages that haven't been touched in a while, and part of that is pruning all the cruft that has been accumulated in package.json over the years.

I was looking for a canonical order to sort the keys by, and thought the order the npm docs specify the configuration options made sense.

Of course, after manually sorting one package.json file—which probably took 2 minutes—I decided to spend 30 minutes to find our how I could automate sorting the other two.

Luckily there's an npm package for everything. With the sort-package-json package you can go sort your package.jsons in a logical order.

npx sort-package-json **/*/package.json

That's all I had to do to keep my monorepo clean and tidy.

You stop to count how many tools and parsers work on your codebase: TypeScript, esbuild, swc, babel, eslint, prettier, jest, webpack, rollup, terser. You are not sure if you missed any. You are not sure if you want to know. The level of pain is so high you forget about anything else.

We've come a long way, but we're not there yet.

Local storage tends to be the obvious place to persist data locally in a web application. We tend to grab straight for localStorage, but it's not the only tool in our workbox. Another option is sessionStorage. Let's review their similarities and differences, and determine when to use which.

Read more

I've been using Alpine often lately. Ryan has written a lot of good stuff on Alpine, but his reusable components post is what really got me kickstarted.

You should be careful to not abstract too early. If you are finding it difficult to manage your Alpine component from the x-data attribute, this one is definitely for you.

The way this article builds up was very helpful: only use the level of abstraction you need:

1. No abstractions
2. Extract to a component function
3. Use x-spread
4. Mix in other data

To execute a piece of code when the viewport is a certain size, the first thing that comes to mind is adding a resize event listener to the window object. This is one way, but not always the best. Sometimes the lesser known window.matchMedia API is a better fit.

Read more

Today, my colleague Freek asked for help embedding the webview of an email campaign in an iframe. He needed it in an iframe because embedding the HTML directly caused layout issues because the website's CSS clashed with it.

After setting up the iframe, we needed to find a way to dynamically resize it based on its contents to avoid double scrollbars on the page. While possible, it required some icky scripting.

I took a step back. The problem at hand was that the CSS needed to be scoped somehow. While iframes were the only solution for a long time, these days we have the shadow DOM.

Read more

I created the original Spatie guidelines site three years ago. Last month, we consolidated a few of our subsites to our main spatie.be site, including the guidelines.

Read more

Jeremy Wagner measured some performance differences between React and vanilla JavaScript. While I'm not surprised that running your code on bare metal code is faster than a framework, it's interesting to see some exact numbers.

React and ReactDOM total about 120 KiB of minified JavaScript, which definitely contributes to slow startup time. When client-side rendering in React is relied upon entirely, it churns. Even if you render components on the server and hydrate them on the client, it still churns because component hydration is computationally expensive.

If it sounds like I have a grudge against React, then I must confess that I really like its componentization model. It makes organizing code easier. I think JSX is great. Server rendering is also cool—even if that’s just how we say “send HTML over the network” these days.

Even with server-side rendering, React and other virtual DOM frameworks add loading time because they need to load more code and hydrate the page before it's interactive.

A vanilla addEventListener callback performs about 40 times faster (!) than an event handled in a React component. React's overhead worth when you have a lot of complex state, not "simple state" like menu toggles.

Read the full article on CSS-Tricks.

If you've dealt with dates in the browser, chances are you've used Moment.js. Moment has been the date library for JavaScript in the past years. In a humble prelude of the documentation, the Moment maintainers talk about the (near) deprecated status of the project.

Read more

Now that we've built a dropdown list, lets add some transitions to create open & close animations.

Read more

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.

Read more

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.

Read more

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?

Read more

After learning how to select elements in the DOM, it's time to zoom into events. This is the third post in the JavaScript Framework Diet series.

Read more