DEV Community: Alan Johnson

Safe Assignment

Alan Johnson — Tue, 10 Sep 2024 04:15:40 +0000

There was a good bit of buzz today about the new proposal for a safe assignment operator (?=) in JavaScript. I love how JavaScript has improved over time, but this is also a problem I've run into in a few cases lately. I should whip up a quick example implementation as a function, right?

In case you haven't read the proposal, here's what it proposes:

const [error, value] ?= maybeThrows();

The new ?= operator would be equivalent to calling the right side of the assignment in a try/catch block, returning an array. The first value of the returned array would be an error if something threw inside the assignment, and the second value would be the result of the assignment if nothing threw.

A Common try/catch Annoyance

I frequently bump into code that feels pretty ugly around assignment and try/catch blocks. Things like this:

let errorMsg;

try {
  maybeThrow();
} catch (e) {
  errorMsg = "An error message";
}

To access errorMsg outside of the try/catch block using const or let you have to define it outside of the block.

A Non-Async Implementation

The easiest case here is handling non-async functions. I was able to whip up
some test cases and a function called tryCatch in no time:

function tryCatch(fn, ...args) {
  try {
    return [undefined, fn.apply(null, args)]
  } catch (e) {
    return [e, undefined];
  }
}

function throws() {
  throw new Error("It threw");
}

// returns a sum
// prints [ undefined, 2 ]
console.log(tryCatch(Math.sqrt, 4));

// returns an error
// prints [ Error: 'It threw', undefined ]
console.log(tryCatch(throws));

tryCatch calls the function with the given arguments wrapped in a try/catch block. It appropriately returns [undefined, result] if nothing throws inside the function, and [error, undefined] if something does throw.

Note that you can use an anonymous function with tryCatch as well if you don't already have a function ready to call.

console.log(tryCatch(() => {
  throw new Error("It threw");
}));

Handling Async Functions

Async functions get a little trickier. One idea I initially had was to write
a completely async version, maybe called asyncTryCatch, but where's the challenge in that. This is a completely pointless exploration! Here's an implementation of tryCatch that works with both async and non-async functions:

function tryCatch(fn, ...args) {
  try {
    const result = fn.apply(null, args);

    if (result.then) {
      return new Promise(resolve => {
          result
            .then(v => resolve([undefined, v]))
            .catch(e => resolve([e, undefined]))  
      }); 
    }

    return [undefined, result];
  } catch (e) {
    return [e, undefined];
  }
}

function throws() {
  throw new Error("It threw");
}

async function asyncSum(first, second) {
  return first + second;
}

async function asyncThrows() {
  throw new Error("It throws async");
}

// returns a sum
// prints [ undefined, 2 ]
console.log(tryCatch(Math.sqrt, 4));

// returns an error
// prints [ Error: 'It threw', undefined ]
console.log(tryCatch(throws));

// returns a promise resolving to value
// prints [ undefined, 3 ]
console.log(await tryCatch(asyncSum, 1, 2));

// returns a promise resolving to error
// prints [ Error: 'It throws async', undefined ]
console.log(await tryCatch(asyncThrows));

It looks a lot like the original version, but with some Promise based code
thrown in for good measure. With this implementation you can call tryCatch when calling a non-async function, and then call await tryCatch when calling an async function.

Let's look at the Promise bit:

if (result.then) {
  return new Promise(resolve => {
      result
        .then(v => resolve([undefined, v]))
        .catch(e => resolve([e, undefined]))    
  }); 
}

if (result.then) checks if the given function (called with apply) returned a Promise. If it did, we need to return a Promise ourselves.

Calling result.then(v => resolve([undefined, v])) causes the promise to resolve to the value the given function returned, if nothing throws.

.catch(e => resolve([e, undefined])) is a little trickier. I originally wrote
it as .catch(e => reject([e, undefined])), but that causes an uncaught error
to fall out of tryCatch. We need to resolve here because we're returning an
array, not throwing an error.

And Finally

I pretty regularly have cases where I need to try/catch but feel like the
explicit try/catch block takes up a ton of space and is annoying for scoping assignments. I'm not sure if I'll use it or not, but this was a fun little exploration.

Mocking ESM Without Loaders

Alan Johnson — Thu, 07 Sep 2023 13:06:30 +0000

I've been using the new node:test based testing framework more and more, and recently hit a tricky issue. I often mock dependencies for a file to keep the test focused on the unit I'm testing and not the entire app. But every bit of research I did about doing that with node:test implied that it's not possible to mock ESM imports right now, and wouldn't be in the foreseeable future without messing with loaders.

Issues and discussions pointed at using tools like testdouble.js and esmock. I wanted to see if I could avoid them before adding a new layer of things I needed to configure.

I explored a few dependency injection options that wouldn't require a loader, and most of those libraries also kind of rubbed me the wrong way. The tended to include a lot of boilerplate code and require specific types of expression, like service classes. Again, I wanted to see if I could keep things simpler.

After a little exploring in RunJS I came up with a pattern that I was happy with.

First, an Example

Here's a quick example of what I'm doing.

users.js:

export async function find(id) {
  return db.query("SELECT * FROM users WHERE id = $1", [id]);
}

get-user.js:

import { find } from "./users.js";

export async function handleRequest(request, response) {
  const user = await find(request.params.id);

  response.status(200).send({ user });
}

get-user.test.js:

import { test } from "node:test";
import { assert } from "node:assert/strict";
import { handleRequest } from "./get-user.js";

test("success", async () => {
  const resp = await handleRequest(fakeRequest("/users/12"));
  assert.equal(resp.statusCode, 200);
});

If I were to run the test above, a query would hit the database when the find function is called. I don't want that to happen because it requires us to set the database up correctly, and in a large test suite that can take a ton of time.

As an aside, my general rule of thumb is that I test the database when I'm testing my data layer, but once I move out of my data layer I tend to mock the database rather than shoving all sorts of data into the database. That tends to be easier and keeps my tests running faster.

Tag Mockable Dependencies

First off, lets update the unit we're testing to tag what data we want to mock. We don't know how that will eventually work, but we can imagine a higher-order function that handles our ability to mock:

get-user.js:

import { find } from "./users.js";
import { mockable } from "./mockable.js";

export const findUser = mockable(find);

export async function handleRequest(request, response) {
  const user = await findUser(request.params.id);

  response.status(200).send({ user });
}

All we changed here is added an import of a non-existent function called mockable that we wrapped our find function in. We exported it because we know we'll need to access it in our test.

No Production Overrides, Ever

The code above would fail since there's no mockable.js yet, so let's write it up. First off, we know in production we want it to return the original function. Piece of cake!

mockable.js:

export function mockable(fn) {
  if (process.env.NODE_ENV === "production") {
    return fn;
  }
}

This won't work anywhere but production, yet, but we know in production it adds limited overhead because really it just returns the original function.

Allow Override

Now, let's build out the override case for mockable. We want mockable to return a callable function, but that function should be able to be overriden. Here's how that looks:

mockable.js:

export function mockable(fn) {
  if (process.env.NODE_ENV === "production") {
    return fn;
  }

  // impl holds the overridden implementation of the function, if it is
  // overridden
  const impl = undefined;

  // call impl or the original function, based on if impl is set
  const wrap = function (...args) {
    if (impl) {
      return impl(...args);
    } else {
      return fn(...args);
    }
  };

  // attach an override function to wrap
  wrap.override = function (fn) {
    impl = fn;
    return fn;
  };

  // clear the override
  wrap.clear = function () {
    impl = undefined;
  };

  return wrap;
}

In the code above we're leaning on closures and the idea that JavaScript functions are objects, so you can set a function as a property of a function! It is very weird but also very useful here.

So our mockable function always returns a function. In production it only returns the original function. Not in production it returns a function that also includes override and clear properties that are callable.

Using Mockable in a Test

Now it's time to update the test to lean on the new mockable implementation:

get-user.test.js:

import { test } from "node:test";
import { assert } from "node:assert/strict";
import { handleRequest, findUser } from "./get-user.js";

test("success", async (t) => {
  // override findUser for this test
  findUser.override((id) => {
    return {
      id,
      name: "Test Tester",
      email: "test@test.com",
      createdAt: new Date(),
      updatedAt: new Date(),
    };
  });

  // clear the override after the test runs
  t.after(() => findUser.clear());

  const resp = await handleRequest(fakeRequest("/users/12"));
  assert.equal(resp.statusCode, 200);
});

Done!

That's it! We have a fairly compact way to override functions in a test using higher-order functions, and not requiring a loader of any sort.

This doesn't cover things like overriding a method on a class, but that's mostly a similar idea with a slightly different implementation.

Writing CSS With JavaScript

Alan Johnson — Sun, 03 Sep 2023 18:03:54 +0000

Don't get me wrong. I'm a big fan of CSS. It does what it does really well, and you can't beat the backward compatibility of web standards. Sometimes, though, I get a little annoyed with the way some of the more modern features are implemented, and with some of the missing features.

For most of the time I've written CSS I've used some sort of preprocessor, like Sass or PostCSS to handle these shortcomings. These usually have their own sets of downsides, like some weird language rules in Sass's case or leaning on the standard in ways that mean annoyances aren't really fixed.

This past week I decided to play with the idea of just using JavaScript to generate some CSS, and I'm pretty happy with the outcome.

This isn't a new idea. CSS in JS is obviously a thing, but that usually implies having component code with CSS right alongside it in some sort of JS based syntax. There's also JSS which is a library for writing CSS with JS.

I had the idea to keep my CSS (written in JS) all in its own files, like I would with Sass or another preprocessor, but instead generate CSS output. Then, since it's just JavaScript, it's trivial to process it with an Esbuild onLoad plugin. And since it's JavaScript it's very easy to do almost anything with it, since it's JavaScript.

The Syntax

The general syntax I landed on was that a stylesheet was a JavaScript module that exports an array of CSS rules.

export default [
  {
    a: {
      color: "red",
    },
  },
];

It's pretty trivial to iterate that array and convert it into some CSS. I pretty quickly realized it was nice to not have to quote properties, so I wrote in support for converting property names in camelCase to kebab-case.

export default [
  {
    a: {
      color: "red",
      textDecorationStyle: "dotted",
    },
  },
];

I also decided that numbers should get a px added after them, since I tend to type px a lot when writing CSS, so that this is valid:

export default [
  {
    a: {
      color: "red",
      textDecorationStyle: "dotted",
      fontSize: 15,
    },
  },
];

I knew I wanted nesting, and since I was using Esbuild to post-process the generated CSS anyway, I was able to lean on it to handle browser unnesting (since browser support isn't quite there on nesting). Building nesting support was pretty trivial. As I iterated style properties, if the value of a property was an object I assumed it was a new nested scope:

export default [
  {
    a: {
      color: "red",
      textDecorationStyle: "dotted",

      "&:hover": {
        textDecorationStyle: "solid",
      },
    },
  },
];

Some Cool Tricks

The nice thing about this model is that it gives you some nice tricks for code reuse. Want to factor someting out into a variable? Feel free:

const red500 = "#f00";

export default [
  {
    a: {
      color: red500,
      textDecorationStyle: "dotted",
    },
  },
];

In this case the red500 variable is doubly nice compared to a css variable because it's a good bit shorter than typing out the variable (it would have been var(--red-500), and most editors give way better tools for refactoring JS variables than CSS variables.

You can still declare CSS variables within this syntax, and even shorten them for yourself while writing them:

const red500 = "var(--red-500)";

export default [
  {
    ":root": {
      --red-500: "#f00"
    },

    a: {
      color: red500,
      textDecorationStyle: "dotted",
    },
  },
];

You can also factor out and reuse whole sets of properties:

const flexRowCentered = {
  display: "flex",
  alignItems: "center",
  justifyContent: "center",
};

export default [
  {
    div: {
      ...flexRowCentered,
    },
  },
];

It's even easy to define reusable media queries:

const mediaSmall = "@media (max-width: 375px)";

export default [
  {
    p: {
      fontSize: 15,

      [mediaSmall]: {
        fontSize: 16,
      },
    },
  },
];

The default export being an array is handy for expanding imported rulesets without having to worry about collisions:

import typography from "./typography.css.js";
import color from "./color.css.js";

export default [...typography, ...color];

All in all, I thought this was a fun little experiment. What do you think?

Minimalist PostgreSQL Migrations

Alan Johnson — Sun, 12 Feb 2023 14:14:35 +0000

There are a ton of database migration tools out there, and they all have a similar set of features. A lot of times the decision on what migration tooling to use is decided by the ORM or database driver you're using.

For a while now I've wanted to dig into what a bare minimum migration tool that uses standard Unix tools and psql, the PostgreSQL CLI, would look like. My goal here is to have something that should work on any general Unix system without having to lean on my ORM or other tools to use it.

Run scripts with psql

To get started, connect to the database with psql. There are several ways to set connection details, but I like to use use a connection string:

set DATABASE_URL=postgres://postgres:postgres@127.0.0.1:5432/mydb
psql $DATABASE_URL

The rest of this post will take for granted that $DATABASE_URL is set.

Once successfully connected, the psql command presents a REPL that allows query input and other psql specific commands. Hitting Ctrl-d will exit psql.

Beyond the REPL mode, psql allows a -f [filename] argument to be passed, which causes it to run the given file.

psql $DATABASE_URL -f script.sql

This is great for the goal of running migrations, because it means a migration in a .sql file composed of a sequence of SQL queries can be run with psql with the -f argument.

There are a few other options on the psql command that look handy. Giving psql the -v ON_ERROR_STOP=1 option, which sets the ON_ERROR_STOP variable to 1 does exactly what it looks like. If an error occurs in a migration, it will return an error status code.

Also -1 looks helpful. It will run an entire -f script in a single transaction.

With all of those commands combined, here's the final psql migration argument set:

psql -1 -v ON_ERROR_STOP=1 -f script.sql

It's a start!

Migration State Management

Most migration systems track state in a table within the database. The table tracks what migrations have and haven't been run, and usually some extra metadata like when they were run.

Here's a table creation query for a basic migration script:

CREATE TABLE IF NOT EXISTS "migrations"(
  "id" integer PRIMARY KEY,
  "migrated_at" timestamptz NOT NULL DEFAULT now()
);

This table has two columns. An id column that tracks the version for a recorded migration, and migrated_at that records the time the migration occurred.

To record to the migrations table, a query like this needs to be run:

INSERT INTO migrations (id) VALUES (1);

It'd be a little annoying to write that each time, though, so why not define
a function within PostgreSQL for inserting a migration version:

CREATE OR REPLACE FUNCTION log_migration(
    id integer
  ) RETURNS void AS $$
  BEGIN
    INSERT INTO "migrations" (id) VALUES (id);
  END;
$$ LANGUAGE plpgsql;

This takes a migration id and records it to the migrations table. It can be run like this:

SELECT log_migration(1);

Because the migrations table exists and typically when a new migration is run it's expected to be working on an existing state of the database, it can also be helpful to have a function that will assert that the database state is as expected.

CREATE OR REPLACE FUNCTION assert_latest_migration (
  id integer
  )
  RETURNS void AS $$
  DECLARE
    latest_id integer;
  BEGIN
    SELECT MAX(migrations.id) INTO latest_id FROM migrations;

    ASSERT latest_id = id, 'migration assertion ' || id || ' failed, current latest is ' || latest_id;
    RETURN;
  END;
$$ LANGUAGE plpgsql;

This one's a little more complicated:

It takes in an expected migration version as an argument.
Queries for the latest migration version in the migrations table, and set it to latest_id.
Compare the expected migration version to latest_id. If they aren't equal, raise an error.

This function can be used like this:

SELECT assert_latest_migration(1);

If the latest migration in the migrations table doesn't match the argument, which in the example above is 1, an error will be raised. This fits nicely with the -v ON_ERROR_STOP=1 option in psql.

Putting all of this together, the first migration file is ready to go:

migrations/000-bootstrap.sql:

CREATE TABLE IF NOT EXISTS "migrations"(
  "id" integer PRIMARY KEY,
  "migrated_at" timestamptz NOT NULL DEFAULT now()
);


CREATE OR REPLACE FUNCTION log_migration(
    id integer
  ) RETURNS void AS $$
  BEGIN
    INSERT INTO "migrations" (id) VALUES (id);
  END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION assert_latest_migration (
  id integer
  )
  RETURNS void AS $$
  DECLARE
    latest_id integer;
  BEGIN
    SELECT MAX(migrations.id) INTO latest_id FROM migrations;

    ASSERT latest_id = id, 'migration assertion ' || id || ' failed, current latest is ' || latest_id;
    RETURN;
  END;
$$ LANGUAGE plpgsql;

SELECT log_migration(0);

Running this with the psql command above will apply it to the database:

psql -1 -v ON_ERROR_STOP=1 -f migrations/000-bootstrap.sql

Adding a Real Migration

Running a migration to set up migrations isn't that satisfying. Here's a first real migration, which creates a table of users:

migrations/001-create-users.sql:

SELECT assert_latest_migration(0);

CREATE TABLE "users" (
  id serial PRIMARY KEY,
  username varchar(255) NOT NULL,
  encrypted_password varchar(255) NOT NULL,
  created_at timestamptz NOT NULL,
  updated_at timestamptz NOT NULL
);

SELECT log_migration(1);

This uses the assert_latest_migration function from above to ensure the database state starts out as expected. It then creates the users table, and closes by using the log_migration function to record the new migration version.

Run it with psql -1 -v ON_ERROR_STOP=1 -f migrations/001-create-users.sql

This minimal migration system seems to be working!

Bulk Executing Migrations

There's a great way to run a single migration, but what about all migrations? There are great Unix command line tools that can help piece together running all migrations.

find will help get a list of all migrations in a directory:

find migrations -iname "*.sql"

This finds all files with a .sql extension in the migrations directory. Find doesn't sort that list, though, so pipe the output from find into sort.

find migrations -iname "*.sql" | sort

This outputs a list of all the filenames sorted. Since psql needs a -f in front of each filename, printf along with xargs can set that up:

find $1 -iname "*.sql" | sort | xargs printf -- '-f %s\n'

And then another xargs runs the migrations:

find $1 -iname "*.sql" | sort | xargs printf -- '-f %s\n' | xargs psql $DATABASE_URL -1 -v ON_ERROR_STOP=1;

This will run all migrations and exit if any of them fail. They'll be run in a single transaction.

Cleaning Up

It's probably not practical to remember and type these psql based commands out, so some simple bash scripts can help give quick commands for running a single migration or running all migrations:

bin/migrate:

#!/bin/bash
set -e

if [ -z ${DATABASE_URL+x} ];
then
  echo "DATABASE_URL must be set";
  exit 1;
fi;

if [ -z ${1+x} ] || [ ! -f $1 ];
then
  echo "Usage: migrate [script.sql]";
  exit 1;
fi;

psql $DATABASE_URL -1 -v ON_ERROR_STOP=1 -f $1;

Running this script will make sure the given argument is a file, and if not it'll give a usage message. Otherwise it'll run the migration script.

bin/migrate-all:

#!/bin/bash
set -e

if [ -z ${DATABASE_URL+x} ];
then
  echo "DATABASE_URL must be set";
  exit 1;
fi;

if [ -z ${1+x} ] || [ ! -d $1 ];
then
  echo "Usage: migrate-all [dir]";
  exit 1;
fi;

find $1 -iname "*.sql" | sort | xargs printf -- '-f %s\n' | xargs psql $DATABASE_URL -1 -v ON_ERROR_STOP=1;

This script expects a directory as an argument, and runs all of the migrations in the given directory, in order.

There's a problem with this script, though, that will take a while to hit. There is a limit to how long an argument can be, and xargs is simply concatenating all files into a huge list. There are limits to how long this argument list can be, though. Run getconf ARG_MAX to see the maximum length of a command. On my computer right now it's 1048576. It's long, but not infinite.

It's ideal to just use a loop in bash instead:

bin/migrate-all (take 2):

#!/bin/bash
set -e

if [ -z ${DATABASE_URL+x} ];
then
  echo "DATABASE_URL must be set";
  exit 1;
fi;

if [ -z ${1+x} ] || [ ! -d $1 ];
then
  echo "Usage: migrate-all [dir]";
  exit 1;
fi;

files=$(find $1 -iname "*.sql"); #| xargs printf -- '-f %s\n' | xargs psql $DATABASE_URL -1 -v ON_ERROR_STOP=1;
for file in $files;
do
  psql $DATABASE_URL -1 -v ON_ERROR_STOP=1 -f $file;
done;

And with that, the minimal migration solution is ready to use.

What's Missing

This isn't the most full featured migration system.

Run only missing migrations

This doesn't currently support running the latest migrations. In practice I don't generally miss that feature, because I prefer to drop my database and rebuild it in development. During deployment it's good to take a minute and think through the migrations that need to be run and review them, rather than just running a migrate command.

Roll Back

It's certainly missing any way to roll back migrations. My general experience is that I seldom to never migrate back, and that frequently migrations aren't able to be undone, so this doesn't bother me too much, but of course your team's mileage may vary there.

The broad strokes of how this system works has been in place at Cardinal for several years now, but we have some JavaScript based scripts rather than bash to tie it all together. It has worked great for us, so I'm confident it can help tons of other teams as well.

The Code

If you'd like to see the full example code from this, check out nalanj/migrations. Feel free to throw an issue or a discussion into that repo.

Automate GitHub Actions Node Version

Alan Johnson — Fri, 07 Oct 2022 18:05:30 +0000

I use GitHub Actions for all my CI, and one annoying thing I hit early on was having to keep my GitHub Actions Node version in sync with the Node version I use for development.

To solve that issue I've switched to using Volta for Node version management. It's nice because it can switch Node versions on the fly based on what's configured in package.json, like this:

{
  //...package.json

  "volta": {
    "node": "18.10.0"
  }
}

Then in GitHub Actions I use these couple of steps to load my Volta version of Node:

# set NODE_VERSION to be Volta's current version
- run: echo NODE_VERSION=$(jq -r .volta.node package.json) >> $GITHUB_ENV
- uses: actions/setup-node@v3
  with:
    node-version: ${{ env.NODE_VERSION }}

An Experiment With Dynamic Loading

Alan Johnson — Wed, 05 Oct 2022 17:03:09 +0000

I've been thinking about how to hot reload within server code to improve my development experience a lot lately. One thing that doesn't appeal to me much is using something like webpack and its HMR implementation, primarily because it has a lot of tricky implementation details when handling things like reconnecting databases, etc.

One idea I had the other day was to simply try out using a Worker within node to handle the reloading. Workers run in their own interpreter, so they should work!

Here's the quick test I wrote up to in fact confirm that using Worker is feasible for dynamic loading:

// index.js
const { Worker } = require("node:worker_threads");

const t = setInterval(() => {
  new Worker("./worker.js");
}, 1000);

// worker.js
console.log("WORKER", "1", new Date());

Running node index.js causes the process to start and spawn a new worker every second. And indeed, if I edit the worker.js file the updates are displayed on the next execution of the file.

It should be feasible to build an HTTP server that loads in a worker on every request and processes the request with the latest copy of the code.

Stop All Docker Compose Related Containers

Alan Johnson — Mon, 11 Jul 2022 19:41:17 +0000

I jump around between projects very frequently, and often those projects use Docker Compose. When moving around I typically go to start Docker Compose in the project I'm about to work on, realize I left it running in another, and then have to cd back to the other directory, stop things, and then cd back.

Today I finally decided to fix the problem. Here's a one-liner that will stop all Docker Compose related containers across your system, regardless of directory:

docker ps -q --filter label=com.docker.compose.project.working_dir | xargs docker stop

Running that will stop all containers without you having to cd into other directories.

A Couple of GitHub CLI Aliases

Alan Johnson — Mon, 21 Mar 2022 14:29:49 +0000

One thing I love about GitHub CLI is that it's easy to define aliases. You can run gh alias set ... to define a new alias and add all sorts of useful commands. Here are two that I use every day:

gh alias set w 'run watch'

I type gh run watch constantly, so shortening it to gh w is very handy.

gh alias set merge 'pr merge -d'

This one makes it where typing gh merge will merge the pr for the current branch, delete the branch on the remote and locally, and switch you back to your main branch.

It's always handy to save a few keystrokes. Define some aliases of your own and share them here in the comments!

Bug Pattern: Ignoring the default case

Alan Johnson — Fri, 04 Mar 2022 13:54:03 +0000

I'm going to be writing up bug patterns as I see them, as a bit of a personal learning project. When I create bugs, what caused me to create them?

This first one I'm going to call Ignoring the default. Imagine this scenario:

You find a tricky bug
You spend a while debugging it
Aha! You finally find the problem. Fix it. You test the reproduction case. You ship the fix.
Time elapses.
A very common case in your application isn't working correctly.

I did this yesterday. What was the problem? I ignored the default case. I got so focused on fixing the error case that I forgot to test the default case and rushed to shipping the fix.

This actually came up due to two issues:

I ignored the default case when I was preparing the fix.
My test coverage didn't cover the default case.

In this particular situation I'm not sure a test for the default case would have made that much sense, but still. I ignored the default case.

Ava and React Testing Library

Alan Johnson — Sat, 19 Feb 2022 14:54:15 +0000

The other day I needed to test a React hook with Ava, which lead me to try to use React Testing Library, and it took me a few minutes to figure out the best way to do so because the documentation to do so was spread over several pages.

I'm working with npm, so adjust commands as needed. First, set up some packages:

npm install react react-dom
npm install --save-dev ava @testing-library/react \
  global-jsdom jsdom

Now we can write a basic test. This is a trivial example, but shows how everything comes together.

import "global-jsdom/register";

import React from "react";
import test from "ava";
import { render, screen, fireEvent, cleanup } from "@testing-library/react";

test.afterEach(cleanup);

function Button() {
  const [state, setState] = React.useState("Hello");

  return <button onClick={() => setState("World")}>{state}</button>;
}

test("setState", (t) => {
  render(<Button />);

  const button = screen.getByText("Hello");
  fireEvent.click(button);

  t.not(screen.getByText("World"), null);
});

The crucial bits for getting this all working:

import "global-dom/register"; sets up jsdom globally in our tests.
test.afterEach(cleanup); makes sure that React Testing Library gets cleaned up after each test.

The rest is just normal React Testing Library usage.

Run Current File with babel-node and VSCode

Alan Johnson — Wed, 03 Feb 2021 13:55:26 +0000

A lot of times I'll open up a scratch file and run it through babel-node to see how it works while spiking out an idea or testing something that's just awkward to test initially otherwise. I wanted to see if there was some good way to get it to run with a keyboard shortcut in VSCode, and I managed to find it! What you want is to bind the workbench.action.terminal.sendSequence command.

To get it set up, open the command palette (Ctrl+Shift+P) and search for Preferences: Open Keyboard Shortcuts (JSON). Now that you have your keyboard shortcuts file open, add a new entry by hitting Ctrl+K Ctrl+K. It'll prompt you to enter the shortcut you want to use. I use Ctrl+r f. Once you enter the mapping, hit Enter and VSCode will add a new keybinding entry to the file. Update that entry to look like this:

{
  "key": "ctrl+r f",
  "command": "workbench.action.terminal.sendSequence",
  "args": { "text": "npx babel-node ${file}\n"},
  "when": "editorTextFocus"
}

That keybinding basically says "When I hit ctrl+r f while in the editor, run npx babel-node on my current file. It's a simple trick, but it can really help save time vs. jumping back and forth to the terminal to run a command on the file.

VSCode Task for Jest

Alan Johnson — Sun, 20 Sep 2020 14:26:50 +0000

I've tried the VSCode Jest extension a few times and never had much success with it. That said, the promise of tests running automatically and failures being added to my error list always seemed cool, so I decided to see if I could piece together a solution with tasks.

First off, set up a Jest Reporter to make it easier to parse the output from Jest. The documentation for reporters is pretty light, but thankfully there are type definitions. Here's what I use:

// custom reporter to make it easier to configure vscode to read problems
class CodeReporter {
  constructor(globalConfig, options) {
    this._globalConfig = globalConfig;
    this._options = options;
  }

  onRunStart(results, options) {
    console.log();
    console.log("-- RUN START");
  }

  onTestResult(test, testResult) {
    console.log(testResult.testFilePath);

    if (testResult.testExecError) {
      console.log(
        `-- failed;${
          testResult.testFilePath
        };1:1;${testResult.testExecError._originalMessage.replace(/\n/g, " ")}`
      );
    }

    testResult.testResults.forEach((r) => {
      if (r.status === "failed") {
        try {
          const stack = r.failureDetails[0].stack.split("\n");

          const frame1 = stack.findIndex((row) => row.startsWith("    at"));
          const location = stack[frame1].match(/[^:]*:([^:]*:[^:]*)/);

          console.log(
            `-- failed;${testResult.testFilePath};${
              location[1]
            };${r.failureDetails[0].message.replace(/\n/g, " ")}`
          );
        } catch (e) {
          console.log("ERROR", e);
        }
      }
    });
  }

  onRunComplete(contexts, results) {
    console.log();
    console.log("-- RUN COMPLETE");
  }
}

module.exports = CodeReporter;

Since it's intended for use in VSCode, I put it in my .vscode directory as .vscode/code-reporter.js.

Now we'll need to set up a tasks.json in the .vscode directory to configure the actual test task:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "test",
      "command": "./node_modules/.bin/jest",
      "args": [
        "--watch",
        "--color=false",
        "--reporters=\"<rootDir>/.vscode/code-reporter.js\""
      ],
      "isBackground": true,
      "problemMatcher": {
        "owner": "javascript",
        "fileLocation": "absolute",
        "pattern": {
          "regexp": "^-- failed;([^;]+);([^;]+);([^;]+)$",
          "file": 1,
          "location": 2,
          "message": 3
        },
        "background": {
          "activeOnStart": true,
          "beginsPattern": "^-- RUN START",
          "endsPattern": "^-- RUN COMPLETE"
        }
      }
    }
  ]
}

This runs jest with --watch and configures the task as a background task. It also parses output using the custom reporter format. There's great task documentation on the VSCode website.

That's it for configuration! To start the test task, hit Ctrl-Shift-P (Cmd-Shift-p on Mac) and choose Tasks: Run Task, and then choose the test task. It will run tasks that changed since the last commit, since that's the default for Jest, but you can interact with the task in VSCode's terminal just like you would interact with Jest in a terminal.

Once tests run you should see error highlighting for any failed tests: