Forem: Sindre Bøyum

Using tagged template literals to syntax highlight code in strings

Sindre Bøyum — Sat, 26 Aug 2023 08:47:56 +0000

Sometimes as developers we have to write code that generates code. This can be for a number of reasons, but one of the most common ones is that we want to generate HTML or CSS from JavaScript. This is a common pattern in libraries like styled-components and Lit, but it's also something you might want to do if you're writing a tool that generates HTML or CSS.

The problem

This code often ends up as strings in JavaScript, and strings get no syntax highlighting. This is because the editor doesn't know that the string contains HTML or CSS, and will therefore highlight it as a regular JavaScript string. This is bad for readability and makes it easy to introduce bugs to the HTML or CSS code.

The solution

We can use a few String.raw "hacks" to make Prettier format CSS and HTML strings!
The String.raw tagged template literal is basically a no-op and won't do any changes to the template string, but if you assign it to a variable with the name html or css, tools like Prettier and VS Code will interpret the string as HTML or CSS respectively ✨

Before:



const myCss = `
  h1 {
    color: hotpink;
  }
`;

const myHtml = `
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>My document</title>
</head>
<body>
  <h1>Hello, world 🌏</h1>
</body>
</html>
`;

After:



const css = String.raw;
const html = String.raw;

const myCss = css`
  h1 {
    color: hotpink;
  }
`;

const myHtml = html`
  <!doctype html>
  <html lang="en">
    <head>
      <meta charset="UTF-8" />
      <meta name="viewport" content="width=device-width, initial-scale=1.0" />
      <title>My document</title>
    </head>
    <body>
      <h1>Hello, world 🌏</h1>
    </body>
  </html>
`;

(Regrettably, dev.to's syntax highlighter doesn't recognize this as CSS or HTML, but try it out in your editor!)

Cover image by Walkator on Unsplash

Improve your Dependabot experience with grouping and version ignoring

Sindre Bøyum — Sat, 19 Aug 2023 08:28:34 +0000

Dependabot is GitHub's tool for automating dependency updates. It's great! But it can be a little noisy. Here are some tips for making it a little less so.

Grouping

Ever had Dependabot create seven PRs for the same dependency update? If you're working with dependencies like Storybook, you probably have. To make it a little smarter, we can tell it to group certain dependencies. The groups keyword lets us create a new group and specify by a pattern which dependencies should be grouped together.

version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: daily
    groups:
      storybook:
        patterns:
          - "@storybook/*"
          - storybook

By doing this, all dependencies that match the regexes will be grouped together in one PR and we no longer get a load of different PRs every week when SB creates a new patch version (no critique of SB here, it's just a very active project!).

Other groups could be angular, eslint, react, and @typescript-eslint.

Ignoring patch updates

For projects that are moved to maintenance, it's sometimes nice to turn off patch updates, especially if maintenance only happens every couple of weeks. This can be done by adding the following to the Dependabot config:

ignore:
  - dependency-name: '\*'
    update-types: ["version-update:semver-patch"]

That will ignore all patch updates for all dependencies. If you want to ignore patch updates for a specific dependency, you can do that too:

ignore:
  - dependency-name: storybook
    update-types: ["version-update:semver-patch"]

Cover image by Xavier von Erlach on Unsplash

Update your Storybook stories from CSF 2 to CSF 3 now!

Sindre Bøyum — Fri, 18 Aug 2023 12:30:25 +0000

Storybook 7 came out earlier this year and together with better performance and type safety the team shipped ✨ Component Story Format (CSF) 3 ✨! In my opinion it makes stories looks nicer and beautifuller and they're simpler to write!

As with a few other updates in Storybook, this one comes with a migration! Just run this to migrate all stories from v2 to v3 (switch out the glob pattern with whatever matches your project):

npx storybook@latest migrate csf-2-to-3 --glob="**/*.stories.ts"

What do the new stories look like, you ask? They went from something like this:

export default {
  title: "My/Story",
  component: MyComponent,
} as ComponentMeta<typeof MyComponent>;

const Template: ComponentStory<typeof MyComponent> = args => (
  <MyComponent {...args} />
);

export const Story1 = Template.bind({});
Story1.args = {
  hello: "world",
};

export const Story2 = Template.bind({});
Story2.args = {
  hello: "🌏",
};

to this:

export default {
  title: "My/Story",
  component: MyComponent,
  // This is the default render method and can be omitted
  render: args => {
    return <MyComponent {...args} />;
  },
} satisfies Meta<typeof MyComponent>;

type Story = StoryObj<typeof MyComponent>;

export const Story1: Story = {
  args: {
    hello: "world",
  },
};

export const Story2: Story = {
  args: {
    hello: "🌏",
  },
};

Note that I'm using satisfies here to provide type safety for the default export. This really doesn't have anything to do with Storybook, but is a nice way of improving the code base a little ✨

Use opaque types to improve typing on basic types

Sindre Bøyum — Wed, 25 May 2022 12:57:58 +0000

Have you ever wanted to give a string field a type alias?

In TypeScript, these are interchangeable:

type Username = string;
type Password = string;

That means that even if we type parameters with A and B:

function logIn(username: Username, password: Password) {}

const username: Username = "username";
const password: Password = "password";

logIn(username, password);

TypeScript won’t stop us from mixing them up:

function logIn(username: Username, password: Password) {}

const username: Username = "username";
const password: Password = "password";

logIn(password, username);

Opaque types is a way to let TypeScript understand what we’re really after, and will make TS shout at us when using the types wrong, just as it would with any other complex type:

type Username = Opaque<string, "Username">;
type Password = Opaque<string, "Password">;

function logIn(username: Username, password: Password) {}

const username: Username = "username";
const password: Password = "password";

logIn(password, username); // 🚨🚨🚨

Read more about them here:
https://codemix.com/opaque-types-in-javascript/

And get the Opaque type from type-fest:
https://github.com/sindresorhus/type-fest/blob/main/source/opaque.d.ts

Photo by Amy Asher on Unsplash

Use depfu and Mergify to automatically merge dependency updates

Sindre Bøyum — Mon, 03 May 2021 09:08:56 +0000

Over the years, I have accumulated quite a few free time projects that one after another become stale. Security alerts keep rolling in and getting all projects up-to-date is exhausting and might feel overwhelming. Let's automate this task!

depfu

For some time, I have updated the projects manually, however this became way too time consuming. Enter depfu, a free (for open source projects) service that keeps your project's dependencies up-to-date by proposing pull requests (PRs) whenever there's a new dependency version. Renovate is a similar service, and would work the same for the purpose of this tutorial. Depfu has made my life much easier – it automatically creates PRs and the only job left for me is to approve and merge the PR. This is all well and good, however with many projects, even this process becomes tedious. Let's try to automate this task even further!

Mergify

Mergify can merge PRs automatically and lets us define rules for when that should happen. Together, depfu and Mergify can automatically keep our dependencies updated.

Actual tutorial

Step 1: Create depfu and Mergify accounts

Before we can start configuring these tools, we'll need to create one account in each service, and give the services the required permissions. Once this is done, depfu will start creating dependency update PRs in the projects that were added in the depfu GUI.

Step 2: Configure Mergify

We can configure Mergify in a .mergify.yml file placed in the root of our project. Mergify has a great deal of example configurations which is very helpful when new to the tool. This configuration is very powerful, however our task is quite simple and doesn't need much writing:

pull_request_rules:
  - name: Automatic merge for depfu pull requests
    conditions:
      - author=depfu[bot]
      - base=main # or master
    actions:
      merge:
        method: merge

That's actually all that we need! We ensure that it was actually depfu that created the PR, then check that the PR will be merged to the main branch. Now, every pull request created by depfu will be merged automatically.

Is automating this a good idea?

We should ask ourselves if we actually want dependency updates to be merged automatically. They should be subject to review and should perhaps not be merged into the codebase uncritically. This can be mitigated by adding automated tests and to run build scripts on every commit. If required checks fail, Mergify won't merge the PR. Also, Mergify has another trick up it's sleeve: We can do a RegEx search on the PR's title. This combines neatly with the fact that depfu adds a (major), (minor) or (patch) label to the end of the PR title. We can filter out major and minor updates, and our final Mergify config now looks like this:

pull_request_rules:
  - name: Automatic merge for depfu pull requests
    conditions:
      - author=depfu[bot]
      - base=main # or master
      - title~=\(patch\)$
    actions:
      merge:
        method: merge

PRs in my repository must be reviewed before merge

Oh, do they now? As said before, Mergify will wait until no required checks fail, and that includes required reviews. No problem (thanks, Julien Danjou)! We can automate PR reviewal as well! Let's add to .mergify.yml:

pull_request_rules:
  - name: Automatic approval for depfu pull requests
    conditions:
      - author=depfu[bot]
    actions:
      review:
        type: APPROVE

  - name: Automatic merge for depfu pull requests
    conditions:
      - author=depfu[bot]
      - base=main # or master
      - title~=\(patch\)$
    actions:
      merge:
        method: merge

Done!

Now, with these new apps and actions, dependency update pull requests will be created, reviewed and merged 🌼automatically🌼! The GitHub Marketplace is filled with gems like these and I encourage you all to explore the list to make life easier and more automated!

Creating a Simple Confirm Modal in Vanilla JS

Sindre Bøyum — Wed, 25 Sep 2019 06:26:01 +0000

Ever tried using window.confirm() before? It's a remarkable method that is very handy whenever you want your users to really be sure of what they're doing. However, have you tried styling it? Just like with window.alert() it's impossible, so we'll need to create our own Confirm Modal. I'll show you how!

What to solve

First, it's useful to map out what we're trying to solve. It's important that our modal can do three things:

Ask the user the question they should answer (e. g. 'Do you really want to delete your user account?')
Let the user say 'Yes'
Let the user say 'No'

Also, for developers, window.confirm() is so easy to use. We don't want to make it much harder for the developers using our custom confirm than it is to do const theyAreSure = window.confirm('Are you sure');.

Another thing the native modal comes with is the modal itself. We don't want the devs using our component to create a lot of markup every time they need to ask their users to confirm something, which means our custom modal needs to produce this markup automatically.

Ultimately, it should

Be easy to use
Not run any code before the user says 'yes'

How to solve it

Markup

For the sake of this tutorial, it's not too important to specify a convoluted markup, so let's just use this simple code as our HTML base:

<dialog class="confirm-dialog">
  <div class="confirm-dialog-question">Do you really want to delete your user account?</div>
  <div class="confirm-dialog-button-group">
    <button class="confirm-dialog-button confirm-dialog-button--false" type="button">Noo</button>
    <button class="confirm-dialog-button confirm-dialog-button--true" type="button">Yes!</button>
  </div>
</dialog>

If you're unfamiliar with the <dialog> element, go check out MDN's documentation about it! As a short introduction, it's a native element supported by Chrome, Firefox and Opera (there is a polyfill as well) which you can use to show a modal with the showModal() method as such:

function createDialog() {
  const dialog = document.createElement('dialog');
  dialog.textContent = '✨✨✨';

  document.body.appendChild(dialog);

  dialog.showModal();
}

JavaScript API

By making use of the Promise API together with async/await, we can solve two of the things we listed earlier: We can make the code easy to use and we can wait for a signal for when (or if) to actually run the code that deletes every user in the db.

Ultimately, we would want the use of our component to look something like this:

async function deleteUsers() {
  const dialog = new ConfirmModal({ 
    questionText: 'Are you sure you want to delete every user?' 
  });

  const deleteEveryUser = await dialog.confirm();
  if (deleteEveryUser) {
    // ...
  }
}

This makes for a easy to use component, but would this work?

JavaScript's await stops code execution until the Promise that it's waiting for has been either resolved or rejected. The Promise can be resolved by a function triggered by an Event and this is how we'll structure our code. When creating a new Promise, we will add an event listener to the two buttons and, depending on which of the buttons is clicked, resolve the Promise to either true or false - whether or not the user confirms.

Solving it

Let's start by creating a ConfirmDialog class for our component. Its constructor will need three things:

The question text
The 'Yes' button's text
The 'No' button's text

class ConfirmDialog {
  constructor({
    questionText,
    trueButtonText,
    falseButtonText
  }) {
    this.questionText = questionText || 'Are you sure?';
    this.trueButtonText = trueButtonText || 'Yes';
    this.falseButtonText = falseButtonText || 'No';

    this.dialog = undefined;
    this.trueButton = undefined;
    this.falseButton = undefined;
    this.parent = document.body;

    this._createDialog();
    this._appendDialog();
  }
}

I've created one method which creates the <dialog> element and its children, one which appends it to the <body>, and one which removes it from the body and then deletes our ConfirmDialog object. They look as such:

  _createDialog() {
    this.dialog = document.createElement("dialog");
    this.dialog.classList.add("confirm-dialog");

    const question = document.createElement("div");
    question.textContent = this.questionText;
    question.classList.add("confirm-dialog-question");
    this.dialog.appendChild(question);

    const buttonGroup = document.createElement("div");
    buttonGroup.classList.add("confirm-dialog-button-group");
    this.dialog.appendChild(buttonGroup);

    this.falseButton = document.createElement("button");
    this.falseButton.classList.add(
      "confirm-dialog-button",
      "confirm-dialog-button--false"
    );
    this.falseButton.type = "button";
    this.falseButton.textContent = this.falseButtonText;
    buttonGroup.appendChild(this.falseButton);

    this.trueButton = document.createElement("button");
    this.trueButton.classList.add(
      "confirm-dialog-button",
      "confirm-dialog-button--true"
    );
    this.trueButton.type = "button";
    this.trueButton.textContent = this.trueButtonText;
    buttonGroup.appendChild(this.trueButton);
  }

  _appendDialog() {
    this.parent.appendChild(this.dialog);
  }

  _destroy() {
    this.parent.removeChild(this.dialog);
    delete this;
  }

Now, for the final part. Let's create the confirm() method. Inside it we need to show the modal, and to create event listeners for the two yes/no buttons and make them resolve to either true or false and then remove every trace of the component itself.

confirm() {
  return new Promise((resolve, reject) => {
    const somethingWentWrongUponCreation = 
      !this.dialog || !this.trueButton || !this.falseButton;
    if (somethingWentWrongUponCreation) {
      reject("Something went wrong upon modal creation");
    }

    this.dialog.showModal();

    this.trueButton.addEventListener("click", () => {
      resolve(true);
      this._destroy();
    });

    this.falseButton.addEventListener("click", () => {
      resolve(false);
      this._destroy();
    });
  });
}

Nice! I've tested it here:

Advanced CSS: Quantity Queries + Creating a Fluid Responsive Grid with Flex + Zero Media Queries

Sindre Bøyum — Fri, 12 Jul 2019 10:37:37 +0000

Styling for every possibility is hard. Doing the CSS work for a ✨CMS generated site✨ where you have no control of the site's markup teaches you quite a few things about making the most out of the limited tools we're blessed with.

The problem

Our designer's latest challenge was this:

Create a grid of rectangles such that it behaves like this on desktop screens:

Use no JS to achieve this, make it work on IE 10 and up, and use no media queries as we want this to be fluid and work on any screen.

At first sight this might seem like a trivial problem to solve. A few flex-properties should solve most of this, but there's a problem here: If there are four items, they should all render on the same row, however if the user adds one more, the first three items should display on one row, then the next two should be rendered on their own row. How can this possibly be done with no JS?

CSS quantity queries to the rescue

Before we dig into the solution, I want to teach you a bit about CSS counting. CSS provides a set of pseudo-classes that together with a bit of clever maths can help us keep track of how many elements there are within a container. Quantity Queries for CSS by Heydon Pickering sums this up nicely, but as a tldr: By using the power of :first-child, :last-child, :nth-child(), and :nth-last-child(), we can e.g. tell how many <li>s there are in a <ul>.

The solution

<ul>
  <li></li>
  <li></li>
  <li></li>
</ul>

:root {
  --margin: 1rem;
}

ul {
  display: flex;
  flex-wrap: wrap;
  list-style: none;
  margin: calc(-1 * var(--margin));
  padding: 0;
}

li {
  flex-basis: calc(33.3333% - (2 * var(--margin)));
  flex-grow: 1;
  flex-shrink: 0;
  margin: var(--margin);
  min-width: 290px;
}

li:nth-last-child(4n):first-child ~ li, 
li:nth-last-child(4n):first-child, 
li:nth-last-child(7n):not(:nth-last-child(14n)):first-child ~ li, 
li:nth-last-child(7n):not(:nth-last-child(14n)):first-child {
  flex-basis: calc(25% - (2 * var(--margin)));    
}

This method uses Heydon Pickering's ingenious Albatross strategy (must-read). The only caveat here is the min-width: 290px. We need to set a minimum width, and this minimum width will make things go sideways on screens narrower than it. Be sure to keep it low!

li:nth-last-child(4n) selects any element that's a multiple of four steps away from the last element (counting from 1). If there are ten elements inside the <ul>, elements number three and seven from the start will be selected (10, 9, 8, (7), 6, 5, 4, (3), 2, 1). li:nth-last-child(4n):first-child) then targets the any element that's a multiple of four steps away from the last element and also the first element. Add a General sibling combinator (~) and you can target every element that follows this first one.

See that the flex-basis changes whenever there's a multiple of four or seven <li> elements inside the <ul>.

Final result

After a little cleanup, here's the final result! (Go to fullscreen version)

Create a Simple Dark Mode with CSS Filters

Sindre Bøyum — Wed, 10 Jul 2019 06:53:26 +0000

So there's this thing you probably haven't heard of called "dark mode". Yeah, you're right, they're everywhere. Let me teach you how to grace the interwebs with even more instances of light on dark! 🌓

Caveat: This tutorial uses the power of CSS Filters, thus isn't supported by every browser. Per July 10 2019, 94.36% of users support it worldwide.

How does filters work?

The CSS filter property lets us add effects with functions such as monochrome, blur, saturate and a few others. Each of these functions take parameters, and because of this, the possibilities are practically endless. The CSS filter MDN page has a few examples and describes them quite well.

.invert-me {
  filter: invert(100%);
}

Another filter function is the ✨invert()✨ function. It takes a percentage (or decimal number between 0 and 1). MDN tells us this:

[The filter function] inverts the samples in the input image. The value of amount defines the proportion of the conversion. A value of 100% is completely inverted. A value of 0% leaves the input unchanged. Values between 0% and 100% are linear multipliers on the effect. The lacuna value for interpolation is 0.

This sounds perfect for creating a simple dark mode! After all, black inverted is white (and vice versa), right? Sure! Let's try just inverting the entire page and see how that looks:

It looks kind of ok already! Apart from the inverted image, the page looks alright. How could we stop the image from inverting? We might be able to do some magic trick by moving the images out of the container, then position them correctly with absolute positioning, however that sounds terrible for ux, dx and a11y, and possibly more abbreviations, so we need to find another way. We could also invert only parts of the page, let's say every <p>, <hx>, <strong>, <ul> and so on, however this might create new problems when trying to invert the background as there might be margins between the elements.

The solution

But wait! The invert of white is black and the invert of black is white... Could this mean that any color inverted an even number of times is just the same color? Of course that's the case! Let's just invert all images back to their original form when inverting the wrapper!

That seems to work! Now every image will be inverted back. We can also use the class no-dark-mode to invert back other elements, such as videos, elements with CSS background images or parts of the page that are already light on dark in color.

Understanding pseudo elements: Display hrefs in printed documents

Sindre Bøyum — Tue, 02 Jul 2019 11:53:43 +0000

Have you ever tried reading a printed out website, then instantly becoming frustrated when you're trying to click the links? Pseudo elements can't really help you much with this, however they might help you a bit by displaying the links' urls! How do you do this, you ask? Let me show you the power of pseudo elements and the attr() function.

Printed documents only have two dimensions, and they aren't even clickable?! How can we tell the user what the underlined text goes to?

By using the content property together with the attr() CSS function, we can display the value of any attribute. As href is an attribute on a elements, surely we can display this too, right? Of course!

<a href="https://dev.to">a link with no clear sign of where it points to</a>

@media print {
  a::after {
    content: ' (' attr(href) ') ';
  }
}

This code will yield the following result:

Granted printed documents have become rare, this is still a neat trick for those of us working with article heavy sites!

Understanding pseudo elements: Creating Simple Tooltips with CSS and HTML

Sindre Bøyum — Tue, 02 Jul 2019 11:32:49 +0000

Tooltips are a nice way to show the user extra info about the site's UI. By making use of CSS attribute selectors and the attr() function, we're able to create a neat little tooltip to show our users extra info that we don't want to add to the element's text. Scroll down to the bottom to see the tooltips in action, or follow along to learn how to make them yourself!

Preface

Before we begin, we need to understand what problems tooltips solve. They help confused users understand the UI we have created. Confused users come in all different shapes and we need to help them all. This means our tooltips must work for

Sighted users
Users with vision impairments
Those using a mouse
Those who prefer navigating the web with only a keyboard

Descriptive text can be added through the use of aria-* attributes, such as aria-label and aria-description, and the keyboard users need the element to be focusable. This pretty much sorts itself out, as any element with a tooltip probably is some kind of a focusable element already (a, button, input, textarea), however should you need to add a tooltip to a div, please think twice to help those of us who won't be able to see that information.

We also need to add some kind of hover effect for those of us using a mouse pointer. Is there a way to neatly combine all these things such that our tooltips make a great developer experience as well? Let's write some code!

Step 1: The HTML

There is not much code to write in the HTML part of this, which is actually great, as it means it won't become a hassle to use it!

Let's start with a simple button:

<button 
  data-tooltip 
  aria-description="Stormy weather ahead!">
  ⚡⚡⚡
</button>

The aria-description attribute makes screen readers read both the text inside the button element, as well as the description text. We'll use the data-tooltip to tell the browser that this element should have a tooltip.

Step 2: Creating a tooltip in CSS

By using pseudo-elements and content: attr(), we can display any of the element's attribute values:

/* Target any element with the `data-tooltip` and `aria-description` attributes */
[data-tooltip][aria-description]::before {
  content: attr(aria-description);
  display: none;
}

[data-tooltip][aria-description]:hover::before,
[data-tooltip][aria-description]:focus::before {
  /* Show the tooltip on hover and focus */
  display: block;
}

Step 3: Styling the tooltip

Ok, now we have a default styled button and some text that pops out whenever we hover or set focus to it. The description can even be read by screen readers! We've done great already, but the UX is not very good for sighted users. Let's fix that!

Check out the final result on CodePen: