I've been working on the new Web Weekly website and implemented the fairly new View Transition Types to trigger different view transitions depending on specific actions. I discovered that the usual feature detection doesn't work. Let's dive in!

View Transitions support is still fairly new across browsers.

MDN Compat Data (source)

Browser support info for View Transitions

111	111	111	144	144	18	18	22.0	111

Of course, it depends on your browser support, but I will go with implementing feature detection when using View Transitions. To do so, it's usually fine to check for document.startViewTransition being available.

// "standard" view transition feature detection
if (document.startViewTransition) {
  document.startViewTransition(() => {
    // update the DOM
  });
}

If you now want to use View Transition Types, the simple feature detection testing document.startViewTransition won't work because startViewTransition can be used with a different syntax.

// only checking for `startViewTransition` won't work for
// browsers not supporting view transition types
if (document.startViewTransition) {
  document.startViewTransition({
    update() {
      // update the DOM
    },
    types: ["theme-switch"],
  });
}

Note that when you pass in the View Transition Types, startViewTransition isn't called with a callback function but with a configuration object containing an update function (the initial callback) and the desired types. Firefox, in my case now, does support startViewTransition but doesn't support the new View Transition object syntax.

It took me a while to figure it out, so here's how you can feature detect View Transition Types.

const supportsViewTransitions = !!document.startViewTransition;
// feature detection for View Transition Types
const supportsViewTransitionTypes = typeof ViewTransitionTypeSet !== "undefined";

if (supportsViewTransitions && supportsViewTransitionTypes) {
  document.startViewTransition({
    update() {
      // update the DOM
    },
    types: ["theme-switch"],
  });
}

And there we go! In this scenario, Firefox will not run any View Transitions because it doesn't support View Transition Types. All the other browsers are good to go then!

You probably know the problem of rounded boxes. You give a box a nice border-radius, everything looks good and all, and poof, if the box hits the viewport edges it looks terrible. I'm just cleaning up some tabs and I'm 100% certain that I'll come back to these snippets in the future. Maybe they're useful to you, too!

Here's Ahmad sharing his conditional border-radius solution:

.card {
  border-radius: clamp(0px, ((100vw - 4px) - 100%) * 9999, 8px);
}

This snippet should definitely come with a code comment because I doubt many people understand what's going on there. I'm not sure I do, even...

Here's Temani's solution:

.box {
  border-radius: calc(sign(100cqi - 100%)*2rem);
}

This is a little better but yeah... Still not very readable.

And here's Una's approach using the new CSS functions:

/* Conditionally apply a radius until you are (default: 4px, or specify second argument) from the edge of your screen */
@function --conditional-radius(--radius, --edge-dist: 4px) {
  result: clamp(0px, ((100vw - var(--edge-dist)) - 100%) * 1e5, var(--radius));
}

/* usage */
.box {
  /*  1rem border radius, default (4px) distance  */
  border-radius: --conditional-radius(1rem);
}

.box-2 {
  /*  1rem border radius, right at the edge (0px distance)  */
  border-radius: --conditional-radius(1rem, 0px);
}

If you look closely, you might discover that it's basically Ahmad's approach above wrapped in a CSS function (--conditional-radius), and I think this makes this CSS so much better. Bring in the complicated CSS once, but hide all its complexity. Nice nice!

Loud and bold disclaimer: I haven't used the following CLI command because I'm still holding onto the old macOS version. I'm not ready to deal with the "Liquid Glass" situation. However, if I upgrade my OS, I want to find this snippet in my bookmarks (aka my blog).

Here's Adam sharing all sorts of tricks to make Apple's new Liquid Glass design language more accessible. He claims that you can nuke it entirely with one CLI command (again, I didn't run it):

defaults write -g com.apple.SwiftUI.DisableSolarium -bool YES

The article is definitely worth reading if you've had enough of all these translucent UI elements.

Jeremy's post describes the Web Platform Dashboard and its underlying API. If you don't know what I'm talking about, here's the Web Platform Dashboard. 👇

The Web Platform Dashboard is wonderful because you can query the data set for baseline status, dates, and specific features. If you're into web platform updates, this site is there to get lost. Luckily, everything's powered by an API, too.

Jeremy's post includes many example snippets to give you an idea of what to query.

I sat down, adjusted the examples, and here's my new script to access all "newly" available baseline features in my terminal via node index.mjs.

import { styleText } from "node:util";

// More info on: https://web.dev/articles/web-platform-dashboard-baseline

const API_BASE_URL = "https://api.webstatus.dev/v1/features";

async function queryWebStatusDashboard(query, featureData = [], token) {
  try {
    const urlBase = `${API_BASE_URL}?q=`;
    let queryUrl = `${urlBase}${encodeURIComponent(query)}`;

    if (token) {
      queryUrl += `&page_token=${encodeURIComponent(token)}`;
    }

    const response = await fetch(queryUrl);

    if (!response.ok)
      throw new Error(
        `Failed to query dashboard ${queryUrl}: ${response.statusText}`
      );

    const { data, metadata } = await response.json();

    featureData = [...featureData, ...data];

    if ("next_page_token" in metadata) {
      const { next_page_token } = metadata;
      return await queryWebStatusDashboard(query, featureData, next_page_token);
    } else {
      return featureData;
    }
  } catch (error) {
    throw new Error(`Failed to query dashboard: ${error.message}`);
  }
}

const renderName = (text) => styleText(["bold"], text);
const renderLink = (text) => styleText(["underline"], text);

function getFormatedFeatures(features) {
  return features
    .sort((a, b) => a.feature_id.localeCompare(b.feature_id))
    .map(
      ({ name, feature_id }) =>
        `${renderName(`${name}`)}\n  - ${renderLink(
          `https://webstatus.dev/features/${feature_id}`
        )}`
    )
    .join("\n\n");
}

async function main() {
  try {
    const newFeatures = await queryWebStatusDashboard("baseline_status:newly");
    const report = getFormatedFeatures(newFeatures);
    console.log(report);
  } catch (error) {
    console.error("Error in main:", error);
    process.exit(1);
  }
}

main();

It fetches the data, paginates if needed, and applies basic formatting.

This tiny script may be valuable for someone.

Here's Alex using one of my favorite TypeScript features — Template Literal Types — to enforce file name conventions in TypeScript.

js
type ImageExtension = `png` | `jp${`e` | ``}g` | `webp`;
type ImageFileName = `${Lowercase<string>}.${ImageExtension}`;
 
const goodName1: ImageFileName = 'doggy1.jpeg';
const goodName2: ImageFileName = 'doggy2.jpg';
const badName: ImageFileName = 'KittyCat.webp';
Type '"KittyCat.webp"' is not assignable to type '`${Lowercase<string>}.jpg` | `${Lowercase<string>}.jpeg` | `${Lowercase<string>}.png` | `${Lowercase<string>}.webp`'.2322Type '"KittyCat.webp"' is not assignable to type '`${Lowercase<string>}.jpg` | `${Lowercase<string>}.jpeg` | `${Lowercase<string>}.png` | `${Lowercase<string>}.webp`'.

I just love this feature. Enforcing string patterns with TypeScript makes me feel like a TS pro. 😅

I was wrangling some Remix TypeScript the other day and wanted to create a server action that receives submitted form data. This form data then should be used to build up a query string, make a request to a secured and hidden GET endpoint and return the result.

// what I wanted to do ...
export async function action({
  request,
}) {
  const formData = await request.formData();
  const queryString = new URLSearchParams(formData).toString();
  
  // make another API call with the constructed query string
  const resp = await fetch(`https://hidden-api.com?${queryString}`)
  
  // ...
}

Easy peasy, that's what URLSearchParams is for, right? When you check MDN, you'll discover that passing FormData into the URLSearchParams constructor is valid. Nice!

Unfortunately, TypeScript isn't happy about passing a FormData type into the URLSearchParams constructor.

ts
const formData = new FormData();
const queryString = new URLSearchParams(formData).toString();
Argument of type 'FormData' is not assignable to parameter of type 'string | string[][] | Record<string, string> | URLSearchParams | undefined'.
  Type 'FormData' is missing the following properties from type 'URLSearchParams': size, sort2345Argument of type 'FormData' is not assignable to parameter of type 'string | string[][] | Record<string, string> | URLSearchParams | undefined'.
  Type 'FormData' is missing the following properties from type 'URLSearchParams': size, sort

But why is FormData not allowed to be used with URLSearchParams? MDN says it should work, it's a common use case, what's up?

The problem is that FormData could also include non-string types such as a submitted File. As always, TypeScript is correct and rightfully complaining — the FormData object could hold data that URLSearchParams can't handle and this would lead to a nasty hard to find runtime exception.

So what's the solution?

I could now iterate over the form data keys and type guard them, but because I know there won't be a submitted file in my FormData quick type casting did the trick for me.

ts
const formData = new FormData();
const searchParams = new URLSearchParams(
  formData as unknown as Record<string, string>,
).toString();

If you want to find more possible solutions, check this related GitHub issue.

I've been doing Angular development lately, and as with any single-page app, the "Let's do everything in JS" approach breaks basic web functionality. Scroll handling is only one example.

But before we get to the problem, let's recognize what browsers are good at — doing web things. If your site relies on server-rendered HTML you get well-working scroll handling out of the box.

If you link to an anchor element (/something#foo), the browser scrolls to it. Do you hit the back button? The browser instantly shows the last page, thanks to the BF cache. And the page is even in the correct scroll position. Browsers are pretty good at handling websites. One might think they're built for this.

Sometimes (often?) SPA frameworks break these standard web features. And of course, then there's more JS added to fix and reimplement what broke.

Here's Angular's RouterModule configured to fix scroll handling.

@NgModule({
  imports: [RouterModule.forRoot(routes, {
    // handle back and forward navigations
    scrollPositionRestoration: 'enabled',
    // handle anchor links
    anchorScrolling: 'enabled'
  })],
  exports: [RouterModule]
})
export class AppRoutingModule { }

anchorScrolling scrolls to anchors if they're available, and scrollPositionRestoration scrolls the previous page to its last position when hitting the back button. Ignoring the fact that there must be an array storing all navigation's scroll positions to reapply them, this works reasonably well. Forward navigations, on the other hand, are scrolled to the top.

But could there be situations when you want to update the URL without scrolling around? You bet!

If you're building a shop search and want to apply filters or sorting (?filter=shoes&order=asc), chances are high that you just want to update the URL and keep the current scroll position. Or, like in my case, maybe you want to open a modal or sidebar, and it should have a URL so you can link to it (?sidebar=reviews). If you're rendering UI in JS, there are plenty of cases in which you just want to update the URL.

So I thought I could slap an attribute onto a [routerlink] and call it a day.

<!-- 
  ⚠️ Before you copy and paste this code ⚠️
  Note that I hoped for the `scrollPositionRestoration` 
  attribute but unfortunately it's not a thing.
-->
<a
  [routerLink]="[]"
  [queryParams]="{sidebar: 'reviews', productId: productId}"
  [scrollPositionRestoration]="false">
  Show all reviews
</a>

But now it gets fun. Let me repeat the previous fact: forward navigations are scrolled to the top. Always? Yes always (unless you work around the core router behavior).

Here's the scroll logic from Angular 17.3 core if you're curious.

private consumeScrollEvents() {
  return this.transitions.events.subscribe((e) => {
    if (!(e instanceof Scroll)) return;
    
    // this part handles back navigations
    if (e.position) {
      if (this.options.scrollPositionRestoration === 'top') {
        this.viewportScroller.scrollToPosition([0, 0]);
      } else if (this.options.scrollPositionRestoration === 'enabled') {
        this.viewportScroller.scrollToPosition(e.position);
      }
      // imperative navigation "forward"
    } else {
      if (e.anchor && this.options.anchorScrolling === 'enabled') {
        this.viewportScroller.scrollToAnchor(e.anchor);
      } else if (this.options.scrollPositionRestoration !== 'disabled') {
        // You'll end up here if you have `scrollPositionRestoration`
        // enabled and navigate forward
        this.viewportScroller.scrollToPosition([0, 0]);
      }
    }
  });
}

Discovering this Angular core code took me a few hours already, but I can't be alone with this issue, can I? Of course not. Here's the GitHub issue from 2018 asking for a way to temporarily disable scrollPositionRestoration.

The proposed framework solution is what I have hoped for: allow setting scrollPositionRestoration on each navigation. But no one seemed to have PR'ed, reacted or cared about the issue.

I tried a few solutions and here are the ones that worked for me:

1. Disable scroll position restoration entirely and roll your own scroll handling. Ufff.
2. Link to a fragment that doesn't exist and trick Angular into not scrolling. Also, ufff.

I was almost leaning into the ugly fragment hack but asked a colleague for a rubber duck session. And looking at the Angular core code, he came up with a dynamic JavaScript getter for the scrollPositionRestoration option.

RouterModule.forRoot(routes, {
  get scrollPositionRestoration() {
    const params = new URLSearchParams(window.location.search);
    if (params.get('sidebar')) {
      return 'disabled' as const;
    }
    return 'enabled' as const;
  },
  scrollOffset: [0, 164],
  anchorScrolling: 'enabled',
});

Whenever Angular updates the URL and checks if it should scroll around by accessing this.options.scrollPositionRestoration, the current URL is checked. If it includes a query param that shouldn't trigger scrolling (sidebar), scrollPositionRestoration returns disabled. Otherwise, it'll be enabled, and Angular will do its "scroll magic".

Is this a perfect solution? I doubt it. Will there be edge cases where this approach leads to bugs? Most likely. Does it do the trick for me right now? Absolutely, because it's way better than rolling my own scroll handling or adding ugly URLs to the app.

Here's Temani Afif once again doing what he does best: creating wild single-element tricks. What's on this time?

The preview below shows the article's result, which is two image elements.

The img elements are displayed as 3D boxes and only reveal their image content when hovering. There are no div wrappers or anything — what you see above are two img elements.

Temani walks you through how to create this effect step by step; go check it out. It's a great read.

But one thing stood out in the article: you might think that the images hide and show with some wild CSS tricks, but the effect uses good ol' padding-right.

Here's a minimal example.

[Interactive component: visit the article to see it...]

By applying full-width padding to the image, the actual image is "pushed out" of the container. The applied object-fit: cover then prevents the image from being squished. And as the cherry on top: if you change object-position from left to right, the revealing effect becomes a "slide in". Go and try it above!

I don't know when and if I'll use this effect, but it's more than worth a snippet entry on this blog. Thank you, Temani!

Kyle Shevlin blogged about his belief in detailed atomic commits at work. On the contrary, he changes entire projects with a single commit in side projects. I feel you, Kyle.

To improve the side hustle commit chaos, Kyle added a make command called checkpoint to at least occasionally add progress to version control.

I have the same YOLO commit traits and, of course, I love this approach!

But I don't use make, so I created a more general solution as a custom Git command.

A git-yolo shell file now defines my new git yolo command that's based on Kyle's original script.

#!/usr/bin/env sh

echo "🚀 You only live once, right?"
echo ""
git add -A
git commit -m "yoloing at $(date '+%Y-%m-%dT%H:%M')"
git push
echo ""
echo "⬆️  Yolo Checkpoint created and pushed to remote."

As a result, whenever I don't feel like (or don't care about) maintaining a clean Git history — git yolo will do the job.

$ git yolo
🚀 You only live once, right?

[main 23c80e0] yoloing at 2024-03-30T08:22
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 fo
...
...

⬆️  Yolo Checkpoint created and pushed to remote

The Git history will then include some "yolo checkpoints" — at least.

$ git log 

commit 23c80e... (HEAD -> main, origin/main, origin/HEAD)
Author: stefan judis <stefanjudis@gmail.com>
Date:   Sat Mar 30 08:22:07 2024 +0100

    yoloing at 2024-03-30T08:22

commit 53yd07... (HEAD -> main, origin/main, origin/HEAD)
Author: stefan judis <stefanjudis@gmail.com>
Date:   Sat Mar 30 08:10:23 2024 +0100

    yoloing at 2024-03-30T08:10

Nice nice!

Sometimes, I'm surprised about how smart TypeScript is. Let's assume you want to type your app's release version numbers. The format is [releaseMonth]-[releaseYear]. There won't be a new version every month or year.

How hard is it to define a type for this? It's not hard at all.

js
// define release years
type releaseYear = '2022' | '2023' | '2024';
// define release months
type releasteMonth = '03' | '07' | '11';
// combine the two types in a template literal type
type versionNumber = `${releasteMonth}.${releaseYear}`;
 
const version: versionNumber = '04.2022';
Type '"04.2022"' is not assignable to type '"03.2022" | "03.2023" | "03.2024" | "07.2022" | "07.2023" | "07.2024" | "11.2022" | "11.2023" | "11.2024"'. Did you mean '"03.2022"'?2820Type '"04.2022"' is not assignable to type '"03.2022" | "03.2023" | "03.2024" | "07.2022" | "07.2023" | "07.2024" | "11.2022" | "11.2023" | "11.2024"'. Did you mean '"03.2022"'?

For these situations, TypeScript defines Template Literal Types based on good old template strings. Sweet!

Disclaimer: be aware that turning off password manager functionality is generally a bad idea. The general rule is that it should always be the user's choice when to autofill an input field.

The WCAG Accessible Authentication criterion defines that filling forms with assistance like password managers must be possible. If you go against this rule, there must be a good reason. Ideally, this reason is evaluated with user testing.

A situation I can think of is a field that must have name="name" for technical reasons but doesn't match the account user name. Constantly popping up completion dialogs can harm UX in this situation. There are probably more situations. But the rule stands: always evaluate if it's worth breaking password autofill functionality for all users.

Thanks to Sandrine and Scott for providing feedback.

Let's get to it!

Flavio shared how to tell 1Password not to interact with an input element on localhost.

Ignoring the question of when you would want to turn off automatic password filling, how hard can it be to tell browsers and password managers not to mess with an input field?

As Flavio shared, 1Password relies on data-1p-ignore. Fair enough. This attribute is oddly specific, though.

How can you turn off auto-completion for LastPass users, then? Add data-lpignore="true" to your input field and change the "Advanced Settings". Easy. For Bitwarden it's data-bwignore.

But I'm a happy Dashlane user; how about this one? Dashlane created an entire spec called Semantically Annotated Web Forms to handle form completion. An easy data-form-type="other" will do it for this password manager.

Here's a complete attribute list.

And all these data attributes bring us to this beautiful markup to disable password managers for a form element.

<input type="password"
  autocomplete="off" data-1p-ignore data-bwignore
  data-lpignore="true" data-form-type="other">

Isn't it beautiful? And that's only the four password managers I know. I bet there are many others out there...

But to take a step back, isn't the autocomplete="off"'s job to turn off field completion?

As far as I understand, that was the idea behind the attribute, but here's a quote from MDN:

Ignoring autocomplete="off" is a conscious security, accessibility and UX decision. People often know best when they want to autofill a field.

Anyways... do you know any other tricks to turn off password managers? If so, I'd love to hear them because collecting the required attributes for 1Password, Dashlane, Bitwarden and LastPass took me reading way more Stack Overflow threads than it should have.

👏 Shoutout to Kasper Mikiewicz, who provided the Bitwarden attribute.

Here's Kilian over on the Polypane blog with a nice explanation of how to create text that fades out with CSS mask-image.

Using mask-image is smart.

[Interactive component: visit the article to see it...]

Nice one! Bookmarked for later.😉

David Darnes shared a nifty tiny trick to build a "scroll to top" component that automatically shows up after you scroll down a little.

And thanks to modern CSS, position: sticky is all you need. 💙

Here's a scroll-top link in action. 👇

[Interactive component: visit the article to see it...]

Either way, this is a nifty little CSS trick. Thanks, David!

Removing event listeners from DOM elements is pretty annoying because you must have the registered event handler function at hand.

function handleEvent() { /* ... */ }

// add an event listener
document.querySelector('button')
  .addEventListener('click', handleEvent);

// to remove an event listener, the event type ('click') 
// and the function ('handleEvent') have to match 
// the `addEventListener` call
document.querySelector('button')
  .removeEventListener('click', handleEvent);

With somewhat modern JavaScript, you could also use AbortSignals or the once config option to remove event listeners, but what if it isn't your source code that's adding event listeners? What if there's one annoying 3rd party script messing with your events and you have to keep it?

Today I learned about a nuclear option to remove all existing event listeners.

const button = document.querySelector('button);

// replace the element with a copy of itself
// and nuke all the event listeners
button.replaceWith(button.cloneNode(true));

Boom! And that's it — replacing a DOM element with a cloned version of itself removes all previously registered event handlers. Pretty handy!

<!-- This event handler will be copied when you cloned the node -->
<button onclick="console.log('Still here!')"`>click me</button>

If you want to see this pattern in action, here we go. 👇

[Interactive component: visit the article to see it...]

How do you replace an array element at a given index?

Is this a trick question? Not really.

const numbers = [1, 2, 3, 4, 5];
numbers[1] = 'new value';
console.log(numbers); // [1, 'new value', 3, 4, 5]

But when you're using React or any framework betting on immutability, changing an array entry will lead to subtle bugs because the array will still be the same object with the same reference. In an immutable world, data updates always have to result in a new object reference.

How can you change an array element via its index and spit out a new array in the same go then? A 12-years-old Stack Overflow question with 1.5m views has tons of advice, but because it's so old and has hundreds of upvotes, it's not showing the most modern solution in the top area.

Let's have a quick look at creative answers.

You certainly could iterate over the array and build up a new one with a good old forEach loop.

function changeItem(array, index, newValue) {
  const newArray = [];
  array.forEach((num, i) => {
    if (i === index ) return newArray.push(newValue); 

    newArray.push(num);
  })
  return newArray;
}

const numbers = [1, 2, 3, 4, 5];
const updatedNumbers = changeItem(numbers, 1, 'new value');
console.log(numbers);                    // [1, 2, 3, 4, 5]
console.log(updatedNumbers);             // [1, 'new value', 3, 4, 5]
console.log(numbers === updatedNumbers); // false

But this isn't great. Changing an array entry with map is slightly better...

function changeItem(array, index, newValue) {
  return array.map((value, i) => {
    if (i === index) return newValue;

    return value;
  })
}

const numbers = [1, 2, 3, 4, 5];
const updatedNumbers = changeItem(numbers, 1, 'new value');
console.log(numbers);                    // [1, 2, 3, 4, 5]
console.log(updatedNumbers);             // [1, 'new value', 3, 4, 5]
console.log(numbers === updatedNumbers); // false

And for the creatives, if you belong to this small group who remember the difference between slice and splice, you could also use one of these.

function changeItem(array, index, newValue) {
  return [
    ...array.slice(0, index),
    newValue,
    ...array.slice(index + 1)
  ];
}

const numbers = [1, 2, 3, 4, 5];
const updatedNumbers = changeItem(numbers, 1, 'new value');
console.log(numbers);                    // [1, 2, 3, 4, 5]
console.log(updatedNumbers);             // [1, 'new value', 3, 4, 5]
console.log(numbers === updatedNumbers); // false

Okay, this one (☝️) is actually terrible.

But what if I told you that copying an array and changing a single entry is cross-browser supported in JavaScript today?

All modern browsers support with() these days.

MDN Compat Data (source)

Browser support info for Array.with()

110	110	110	115	115	16	16	21.0	110

And with it, this entire exercise becomes a nifty one-liner.

const numbers = [1, 2, 3, 4, 5];
const updatedNumbers = numbers.with(1, 'new value');
console.log(numbers);                    // [1, 2, 3, 4, 5]
console.log(updatedNumbers);             // [1, 'new value', 3, 4, 5]
console.log(numbers === updatedNumbers); // false

Thank you modern JavaScript!

I live in Germany, and while many think we have things in order here, we still need to sort out bureaucracy. It's a clu**fu** at best because German officials rely on paper – paper and handwritten signatures.

It can go so far that a scanned document image is preferred over a nice and sharp PDF. I don't own a printer, let alone a scanner, so occasionally, I drag myself to the local copy shop to do official business.

Until now! I've been browsing Hacker News, and the shell script below takes a PDF and makes it look like it's been scanned.

#!/bin/sh
ROTATION=$(shuf -n 1 -e '-' '')$(shuf -n 1 -e $(seq 0.05 .5))

convert -density 150 $1 \
  -linear-stretch '1.5%x2%' \
  -rotate ${ROTATION} \
  -attenuate '0.01' \
  +noise  Multiplicative \
  -colorspace 'gray' $2
  

Suppose you called the script index.sh, you can now run the following command...

./index.sh original.pdf scanned.pdf

... to scan your PDFs without a physical scanner.

Side note: the convert command is part of the imagemagick tools and wasn't available on my machine. You might have to install it first. A brew install imagemagick did the trick for me, though.

Yoav Kadosh shared a very useGlobalState React hook.

const store = {};
const listeners = {};

function useGlobalState(key, initialValue) {
  const [state, _setState] = useState(store[key] || initialValue);
  const setState = useCallback((stateOrSetter) => {
    let next = stateOrSetter;
    if (typeof stateOrSetter === "function") {
      next = stateOrSetter(store[key]);
    }

    listeners[key].forEach((l) => l(next));
    store[key] = next;
  }, []);
  useEffect(() => {
    // Store the initial state on the first call with this key
    if (!store[key]) {
      store[key] = initialValue;
    }
    // Create an empty array of listener on the first call with this key
    if (!listeners[key]) {
      listeners[key] = [];
    }
    // Register the observer
    const listener = (state) => _setState(state);
    listeners[key].push(listener);
    // Cleanup when unmounting
    return () => {
      const index = listeners[key].indexOf(listener);
      listeners[key].splice(index, 1);
    };
  }, []);
  return [state, setState];
}

You can then use the defined useGlobalState hook to share or update application state across components. 💪

const [state, setState] = useGlobalState('someUniqueKey', INITIAL_STATE);

Are there downsides to this pattern? I don't know, and I'm a little puzzled why I haven't seen this userland hook before, but if you think useGlobalState is a bad idea, let me know!

If you want to learn more, Yoav explains how it works on his blog!

I've been writing JavaScript for so long that I sometimes don't see its quirks. To be fair, there are fewer quirks than ten years ago, but some things would still make great language additions. One thing that would make a lot of sense is required function parameters.

Assume you have a function that defines required arguments. And you really really want to make sure the function is called with the correct arguments by throwing an error.

Here's what you might do:

function doSomethingWithAThing(theThing) {
  if (typeof theThing === "undefined") {
    throw new Error("theThing is required");
  }
}

That's quite a bit of code for such a simple thing.

Unfortunately, you can't do something like this in JavaScript ...

function doSomethingWithAThing(
  theThing = throw new Error("theThing Is Undefined")
) {
  // ...
}

... because JavaScript doesn't like it.

Peter Kröner published a handy snippet that he carries around from project to project. The post is in German, so here's the English gist of it.

First, define a fail function.

function fail(reason, ErrorConstructor = Error) {
  throw new ErrorConstructor(reason);
}

And second... use it. 🫣

By restructuring the code and transforming the error throwing portion into an expression, you can immediately throw in case a function is called without the required parameters.

function doSomethingWithAThing(
  theThing = fail('theThing Is Undefined')
) {
  // ...
}

What a beautiful sort of one-line workaround.

Thanks Peter!

Did Chris just publish a post and unveil the solution to a long-lasting CSS problem almost in a side sentence? It seems like it!

What of the many are we walking about? We're talking about animating (or transitioning) an element's height from 0 to something (auto) just with CSS. That's right – this is possible in all modern browsers today. No JavaScript required!

Not too long ago, browsers shipped animatable CSS grid columns and rows which you could use to fly in a side menu or do fancy stuff like Michelle Barker. 👇

I've never considered using animated grid rows to hide grid cells, though.

Here's the CSS trick to transition or animate an element's height to auto:

1. define a grid container
2. define a single grid row with 0fr
3. add a transition for grid-template-rows
4. set overflow: hidden to the one element inside the grid
5. redefine the grid-template-rows to be 1fr with a CSS class or attribute selector

.grid {
  display: grid; /* 1 */
  grid-template-rows: 0fr; /* 2 */
  transition: grid-template-rows 0.5s ease-in-out; /* 3 */
}

.grid.open {
  grid-template-rows: 1fr; /* 5 */
}

.grid-inner {
  overflow: hidden; /* 4 */
}

And voila! You can now animate an element's height without any hardcoded values. It's just CSS — toggle a class and call it a day! CSS Grid figures out all the rest.

[Interactive component: visit the article to see it...]

I. Am. Blown. Away!

But to Chris' point, even though this technique works, it'd be nice to have an easier way to animate element heights in CSS. I 100% agree but for now, I'll take this approach because it's the best we got! Thanks Chris! 💯

Wes Bos has advocated using the trash-cli instead of the rm command this week.

The reasoning: rm is unrecoverable. Once you remove files or directories using rm, they're gone. Ergo, you can bring yourself into real trouble using rm.

trash can help out here! The command doesn't delete files but moves them to your operating system's trash directory. When you then accidentally delete something important, head over to your lovely bin icon and recover files from there!

But here's the kicker: installing the global trash-cli package comes with 829 dependency files. Markdown, JavaScript, JSON and license files are all at your service, making up a whopping 4.3MB heavy node_modules directory.

Sure, 4 MB isn't an issue for me on my developer machine. And the command runs fast enough to protect me and my fat fingers from self-destruction. But still, that's a lot of dependency code to move files into another directory, isn't it?

Liran Tal thought the same and shared a nifty four-liner giving you all of trash's functionality.

trash() {
  echo "[x] moving files to trash..."
  mv "$@" "$HOME/.trash"
}

I played around with Liran's function and adjusted it also to support multiple files.

# ✅ globs          – `trash file-*-.txt`
# ✅ directories    – `trash directory`
# ✅ multiple files - `trash file-1 dir-1 file-2`
function trash() {
  echo "🗑️  Moving files to trash..."

  for var in "$@"
  do
    mv "$var" "$HOME/.trash"
  done
}

So far, my new trash command has been working great. I'll let you know when I'll discover any issues!

Not too long ago, I was looking into refactoring my site to go all in with CSS grid!

I've been aiming for a classical centered blog layout with flexible side margins. The content should be 65 characters wide at max. But (!) I wanted to be able to break free, and some components should go full-width by setting a class. And it should all work with CSS grid.

After fiddling with it for a while, I didn't reach a satisfying result and decided to do it another day. In the meantime, Ryan Mulligan's post "Layout Breakouts with CSS Grid" provided the CSS solution I was looking for (see it in action on CodePen).

Put all your content in a content wrapper element that defines named grid areas:

.content {
  --gap: clamp(1rem, 6vw, 3rem);
  --full: minmax(var(--gap), 1fr);
  --content: min(50ch, 100% - var(--gap) * 2);
  --popout: minmax(0, 2rem);
  --feature: minmax(0, 5rem);

  display: grid;
  grid-template-columns:
    [full-start] var(--full)
    [feature-start] var(--feature)
    [popout-start] var(--popout)
    [content-start] var(--content) [content-end]
    var(--popout) [popout-end]
    var(--feature) [feature-end]
    var(--full) [full-end];
}

And then control all the component widths using grid template areas. 💯

.content > * {
  grid-column: content;
}
.popout {
  grid-column: popout;
}
.feature {
  grid-column: feature;
}
.full {
  grid-column: full;
}

The post even includes a beautiful visualization that explains what's going on. 👏

I love it. 💙 Thank you, Ryan!

Jim Nielsen shared how to detect Apple’s “New York” font face, and while reading the post, I realized that I'd forgotten about document.fonts. 🙈

The CSS Font Loading API enables you to access or load fonts via JavaScript. It's good stuff!

And if you want to test if a browser supports a font, the check method's your friend!

document.fonts.check('12px ui-serif');

Many of my projects include Node.js scripts to perform setup or teardown steps. And while I could run all of them with the node binary (node create-thumbnails.js), I prefer to remove the file extension and make the scripts executables (./create-thumbnails). This approach saves characters, and makes me feel like a hacker!

My steps to create an executable are:

• Remove the .js file extension (mv create-thumbnails.js create-thumbnails).
• Make the file executable (chmod 744 create-thumbnails).
• Add a shebang (#!/usr/bin/env node) to signal that the executing shell should use the node binary.

Et voilà, you just created a Node.js executable!

This approach has served me well for CommonJS-based scripts using the require function. But it's 2022, and I planned to adopt ECMAScript modules in Node.js executables. Unfortunately, it's not that easy.

But what's the problem?

There are three ways to enable ECMAScript modules in Node.js:

1. use the .mjs file extension
2. have a surrounding package.json with a "type": "module" field
3. call node with the --input-type=module flag

My executables should work without a file extension, which rules out the first option. I also don't want to declare all files as module files or add a package.json, so the type field is out, too.

The --input-type flag looks promising at first, but it only works for strings you pipe into the Node binary yourself.

# pipe JavaScript code into the node binary
echo "import { mkdir } from 'node:fs/promises';" | node --input-type=module

Why's there no flag to enable modules when running a file?

I spent the last 15 minutes reading Node.js issues and discussions about the topic, and I still can't answer this question. If you want to read more, here's a very long GitHub discussion on why such a flag isn't available yet.

Knock yourself out, the discussion takes many turns, and folks have strong opinions!

There are multiple ways to make ECMAScript module-based executables work. They all come with slightly different spins but use the same trick.

Axel recommends the following for UNIX environments.

#!/bin/sh
':' // ; cat "$0" | node --input-type=module - $@ ; exit $?

import * as os from 'node:os';

const {username} = os.userInfo();
console.log(`Hello ${username}!`);

This snippet is wild! In short, it does the following:

• the cat command reads the current file (the executable itself)
• the file content is then piped into node with the --input-type flag
• all the original parameters are handed over to node, too ($@)
• the node call's exit code is caught and propagated to the executable

This instruction makes the file read and pipe itself into the node binary because there's no flag to enable modules. Wow! 🤯

As said, this post is only for my reference. Here are more resources if you want to learn more about other approaches or make it work on Windows.

• Node.js: creating ESM-based shell scripts for Unix and Windows
• Passing options to node on the shebang (#!) line
• NodeJS Executable Standalone Module

Just parking this CSS snippet on my blog for my future self. 🙈

If you want to select elements only when there's a given number of them, you can use a :nth-last-child() selector combination.

The following selector combination is called a "quantity query".

li:nth-last-child(n+3),
li:nth-last-child(3) ~ li {
  color: red;
}

And it selects all list elements when there are at least three of them. See it in action below. 👇

[Interactive component: visit the article to see it...]

The CSS selector is hard to read but works. 🫣

The quantity query above is based on some selector trickery and definitely hard to remember. Luckily, the new :has() pseudo-class is on its way to cross-browser support to simplify such monstrosities!

MDN Compat Data (source)

Browser support info for `:has()`

105	105	105	121	121	15.4	15.4	20.0	105

With :has() the quantity query becomes a resonable one-liner that reads as "Select all li elements in a list that includes a third last child counting from the end."

[Interactive component: visit the article to see it...]

Boom! And that's all it takes to select elements from a list with at least three items. 🎉

And even exact matches are possible by selecting "all list elements in a list including a list element which is the third and last child."

[Interactive component: visit the article to see it...]

:has() is a gift that keeps giving!

Jim Nielsen blogged about a mind-boggling feature of the new :has() pseudo-class. The pseudo-class isn't cross-browser supported yet, but this CSS addition unlocks countless use cases that Frontend engineers have been dreaming of for years.

Here's the current browser support according to MDN.

MDN Compat Data (source)

Browser support info for `:has()`

105	105	105	121	121	15.4	15.4	20.0	105

When I heard first about :has(), I thought it's only the long-awaited "parent selector", but Jim shared that it's the "previous sibling selector", too! 🤯

/* 
  Select every <a> element that's a child of 
  a <p> element that directly precedes an <hr> element.
*/
p:has(+ hr) a { /* ... */ }

With :has() entering the web platform, we can select elements in all directions — we wanted the "parent selector" but will soon have a selector to match the entire family.

Styling the next and previous siblings becomes a nifty one liner. Let's look at a few examples!

Before getting into the new and fancy things, let's recap how to select next (or following) DOM elements.

To select an element's next sibling, use the adjacent sibling selector (+). The selector will match the element that immediately follows another element.

[Interactive component: visit the article to see it...]

Similarly, the general sibling selector (~) allows you to select all following elements.

[Interactive component: visit the article to see it...]

Are you ready for the :has() selector beauty?

We can now invert these selectors with :has() and match elements in the other direction to select previous siblings. 🤯

Use :has() with the adjacent sibling selector (+) to select the immediately previous element...

[Interactive component: visit the article to see it...]

... or the general sibling selector (~) to match all previous siblings.

[Interactive component: visit the article to see it...]

:has() is a pretty big deal in CSS land and I can't wait until it finally lands in all browsers, so we can match elements in all directions. Up and down! And left and right — the CSS future's bright!