Forem: Ian Walter

Have you dismissed TailwindCSS?

Ian Walter — Sun, 19 Apr 2020 01:29:33 +0000

Maybe you've heard of TailwindCSS but have dismissed it because you think writing out class names for each CSS rule is too tedious and you don't want to "litter" your HTML with them? Well that's understandable since it "encourages a utility-first workflow, where designs are initially implemented using only utility classes to avoid premature abstraction", but that's not the end of the story.

Components can be composed of utility classes using @apply. So the following button:

<button class="bg-blue-500 text-white font-bold py-2 px-4 rounded">
  Click Me
</button>

Can be optimized to use this class:

.button {
  @apply bg-blue-500 text-white font-bold py-2 px-4 rounded;
}

Simplifying it to:

<button class="button">
  Click Me
</button>

Pseudo-classes can't be used with @apply so if you wanted to use hover:bg-blue-700 with the button class you would simply add a separate pseudo-class for the underlying utility class:

.button:hover {
  @apply bg-blue-700;
}

So why do this instead of just using CSS rules directly?

Because now you benefit from the convenience of the button component class and you can still use the utility classes to compose other components, style other areas of your site, and easily modify the styles of other elements. The flexibility that utility classes provide is extremely powerful and, because of how it works behind the scenes, the generated CSS is smaller than if you had specified CSS rules directly for all of those things (as long as you're using a tool like PurgeCSS).

Read more about this on the TailwindCSS site: Extracting Components

Fixing ChunkLoadError

Ian Walter — Sat, 18 Apr 2020 19:46:02 +0000

I encountered a bug last year that was a bit tricky because it wasn't something that we would ever run into during development but was a legitimate problem in production. I found the bug because I set up Sentry for our client application and it was reporting that there were unhandled exceptions being thrown with the name ChunkLoadError. It would happen consistently in production but rarely, if ever, in the master and stage environments.

Because of the name, I immediately understood that this was probably being thrown by the client-side Webpack logic which was failing to load a "page" in our application. Pages are split into separate bundles (also known as chunks) so that users only need to download them when they navigate to a route for that individual page.

At first we thought that the error was caused by mobile users with spotty cell service. The thinking was that a user would try to navigate to a new page, the request would fail because of a weak or interrupted connection, Webpack would throw the error when the request failed, and Sentry would store and report the error when the connection had been re-established. This assumption turned out to be incorrect and lulled us into a false sense of security that the error wasn't one we could fix.

A little later on we enabled the Release Tracking feature in Sentry which allowed us to correlate exceptions to individual releases and I noticed that the the error reports seemed to cluster around new releases.

By trying to replicate a simplified production release locally, I was able to figure out that the problem was one we could fix. The error occurred because each chunk's filename contains a hash based on it's content so that if the content changes, the application would be able to retrieve the updated chunk instead of using the old one stored in the browser's cache.

The manifest of chunk filenames that the application uses is only loaded on a full page load so if a user navigates to the application, we release a new version with updated pages, and, without doing a full page load, the user tries to navigate to one of those pages, the client application will try to request the old chunk filename contained in the manifest. At the time, we weren't using a CDN and instead serving static files directly from the server so requests for the old chunks would fail since they didn't exist within the application server's filesystem.

Using a CDN prevented the error from being thrown since the old chunks would still be cached for a certain period of time, but it didn't solve the core issue since users that were using our application during a new release would still be using the old client application as long as they kept the browser tab open.

I solved this issue by adding a try-catch around the navigation and page import logic so that if a page chunk request fails, the app will do a full page request via window.location instead of just a request for the individual chunk.

Check a DNS record value on macOS using the command-line

Ian Walter — Tue, 10 Mar 2020 13:28:30 +0000

I was manually renewing a SSL certificate with Let's Encrypt using DNS verification and needed to verify that the DNS record had been updated before continuing the process:

host -t TXT <domain>

Make sure to change TXT to whatever record type you're looking for, e.g. CNAME, A, etc.

Selenium WebDriver testing on GitHub Actions

Ian Walter — Sun, 12 Jan 2020 05:33:25 +0000

I've found that running WebDriver-based tests using GitHub Actions is relatively inexpensive and pretty easy to set up and maintain. I'm sure others are doing this already but I couldn't find much on this topic and there are a few gotchas, so here's a summary of my experience getting this up and running.

I am working on a testing library called bff and a plugin for it called bff-webdriver that allows you to run WebDriver-based tests. To continuously test the plugin, I've been using GitHub Actions but only running WebDriver test through the plugin's BrowserStack integration (shout out to BrowserStack for providing the service for free). When my colleague Jim submitted the first PR, however, the CI job failed. This is because the BrowserStack credentials that are stored as secrets in the repo are not shared (otherwise people would be able to submit a PR to your repo with malicious code that can access/leak those secrets). I decided that it was time to not only test the BrowserStack integration but also run the tests with a local Selenium server.

The first thing I needed to do was set up "services" in my workflow file. Services are just Docker images that are run as containers to support your workflow. I first had to set these up for testing a web framework I'm working on called nrg. It was more straightforward in that case because the requests are unidirectional. The web framework makes requests to the Redis and PostgreSQL services and that's it. With WebDriver, it's bidirectional. The test framework makes requests to the Selenium Hub, the Selenium Hub makes requests to the browser services, and the browsers make requests to the server being tested.

Set up the Selenium Hub and a Firefox service (Click here for the whole file):

    services:
      hub:
        image: selenium/hub:3.141.59-gold
      firefox:
        image: selenium/node-firefox:3.141.59-gold
        env:
          HUB_HOST: hub
          HUB_PORT: 4444

ci.yml

(You can set up other browsers like Chrome or maybe even Edge and Safari since GitHub Actions can run Windows and macOS VMs but this is beyond the scope of what I needed).

Next I had to configure a --network-alias option which is used as the hostname for your test server by the browser(s). I also had to specify an environment variable for the Selenium Hub hostname (it's the same name as the service, hub) so that the test framework knows where to make the WebDriver requests as well as an environment variable for the network alias so that my tests know where to tell the browser(s) to navigate.

Set up your server and tests within a container (Click here for the whole file):

    container:
      image: node:13.6
      options: --network-alias testHost
    env:
      SELENIUM_HUB_HOST: hub
      TEST_HOST: testHost

ci.yml

Now in your tests, make requests to http://testHost and that's it, you should now have a WebDriver testing setup using GitHub Actions. If you're interested in a lighter-weight browser testing setup, checkout my Puppeteer GitHub action which makes testing in a headless Chrome environment easier.

Spotlight on decision-tree

Ian Walter — Fri, 25 Oct 2019 19:22:49 +0000

I created decision-tree because I was creating a sort of online quiz and I wanted an abstraction to keep track of state as the user completed questions. With decision-tree, you can create a tree-like structure in which answers to questions determine which question or result is shown next as the user continues through the quiz. As the path (or branch) is constructed, it is stored so that the application can know how the user arrived at a result or allow them to backtrack if necessary.

Let’s take a look at an example. First, we need to construct the tree which consists of objects representing questions, options, and results. I apologize in advance for how geeky this example is:

const decisionTree = new DecisionTree({
  key: 'attribute',
  title: 'What is your greatest attribute?',
  options: [
    {
      key: 'S',
      label: 'Strength',
      leadsTo: 'proficiency'
    },
    {
      key: 'I',
      label: 'Intelligence',
      leadsTo: 'spells'
    },
    {
      key: 'D',
      label: 'Dexterity',
      leadsTo: 'proficiency'
    },
    {
      key: 'C',
      label: 'Charisma',
      leadsTo: 'bard'
    }
  ],
  children: [
    {
      key: 'spells',
      title: 'What are your preffered type of spells?',
      options: [
        {
          key: 'damage',
          label: 'Damage',
          leadsTo: 'mage'
        },
        {
          key: 'healing',
          label: 'Healing',
          leadsTo: 'cleric'
        }
      ],
      children: [
        {
          key: 'mage',
          title: 'Mage',
          description: `
            You are a powerful mage, hurling fireballs at your foes!
          `
        },
        {
          key: 'cleric',
          title: 'Cleric',
          description: `
            You are a knowledgeable cleric, saving your friends by casting
            spells to heal them.
          `
        }
      ]
    },
    {
      key: 'proficiency',
      title: 'What type of weapon are you most proficient with?',
      options: [
        {
          key: 'swords',
          label: 'Swords',
          leadsTo: dt => {
            if (dt.state.attribute === 'D') {
              return 'thief'
            } else {
              return 'fighter'
            }
          }
        },
        {
          key: 'bows',
          label: 'Bows',
          leadsTo: 'ranger'
        }
      ],
      children: [
        {
          key: 'fighter',
          title: 'Fighter',
          description: `
            You are a strong fighter, using your sword to cut down those who
            stand in your way!
          `
        },
        {
          key: 'thief',
          title: 'Thief',
          description: `
            You are a dexterous thief, piercing enemies before they even
            know what hit them.
          `
        },
        {
          key: 'ranger',
          title: 'Ranger',
          description: `
            You are a skilled ranger, felling combatants with your arrows.
          `
        }
      ]
    },
    {
      key: 'bard',
      title: 'Bard',
      description: `
        You are a talented bard, inspiring your party with heroic ballads.
      `
    }
  ]
})

Our decision-tree instance

Once a decision-tree instance is created, we can navigate it by setting answers to questions and calling next like:

decisionTree.set('attribute', 'D').next()
const result = decisionTree.set('proficiency', 'swords').next()

Initial tree navigation

In this example, if the node returned by next has no leadsTo property we can assume that we've reached a result. In the navigation above, we would have arrived at the result:

{
  key: 'thief',
  title: 'Thief',
  description: `
    You are a dexterous thief, piercing enemies before they even
    know what hit them.
  `
}

Initial result

If we wanted to arrive at a different result, we can call prev to go back to the previous question and change our answer like:

decisionTree.prev()
const result = decisionTree.set('proficiency', 'bows').next()

Changing our response to the previous question

Now our result would be:

{
  key: 'ranger',
  title: 'Ranger',
  description: `
    You are a skilled ranger, felling combatants with your arrows.
  `
}

New result

You can see decision-tree in action at the binx health website where it’s being used to power Find My Test, an assessment that helps people determine what kind of sexually-transmitted infection (STI) testing is suited for them: https://app.mybinxhealth.com/find-my-test

I hope this article was helpful in explaining how you would use decision-tree. If you find this utility useful, please star it on GitHub and consider sponsoring me!

[

ianwalter/decision-tree

A utility for traversing decision trees by selecting options - ianwalter/decision-tree

ianwalterGitHub

](https://github.com/ianwalter/decision-tree)

Spotlight on vuex-reset

Ian Walter — Wed, 23 Oct 2019 03:10:11 +0000

Vuex makes it easy to manage the app-wide state for a Vue.js application, but there is no built-in way to easily reset that state to it’s initial value. That’s where vuex-reset comes in. It’s a small Vuex plugin that will allow you to reset a store and/or store module(s) to it’s initial state by calling a special reset mutation.

At binx health we're always trying to think of ways we can prevent leaking user information. We use vuex-reset to clear user information after it’s not needed anymore, like when a customer has finished placing an order or has logged out. Although that data is not accessible outside of our application, clearing that data provides a secondary safeguard around leaking that information in ways we did not intend.

Security isn’t the only use-case, though. The utility is generally useful whenever you need to reset state without having to write more code to do so. Let's look at an example in which a form has it's fields bound to a Vuex module's state:

import Vuex from 'vuex'
import VuexReset from '@ianwalter/vuex-reset'

// Create a Vuex store.
export default new Vuex.Store({
  // Add the vuex-reset plugin to the store.
  plugins: [VuexReset()],
  modules: {
    // The colorScheme module has initial values that we may want to 
    // reset to at some point.
    colorScheme: {
      namespaced: true,
      state: {
        name: 'Default',
        colors: [
          '#ff8080',
          '#95ffa4',
          '#ffe9aa',
          '#91ddff',
          '#c991e1'
        ]
      },
      mutations: {
        // We need to add a dummy reset mutation so we can trigger 
        // the reset when desired.
        reset: () => {},
        // Here is an example mutation that can be used to update the   
        // colorScheme values.
        save: (state, colorScheme) => Object.assign(state, colorScheme)
      }
    }
  }
})

store.js

export default {
  data () {
    // Copy the color scheme stored in the Vuex module to the 
    // component's data so it can be used as the default value
    // in the imaginary New Color Scheme form.
    return { colorScheme: this.$store.state.colorScheme }
  },
  methods: {
    save () {
      // Save the new color scheme values from the imaginary New
      // Color Scheme form to the store.
      this.$store.commit('colorScheme/save', this.colorScheme)
    },
    reset () {
      // Reset the color scheme to the initial 'Default' color scheme.
      this.$store.commit('colorScheme/reset')
    }
  }
}

NewColorScheme.vue

When a user first navigates to the imaginary New Color Scheme form in the NewColorScheme.vue component the default values will be the initial values in the Vuex colorScheme module. They can then modify the name and colors of the color scheme and click a save button which would save those updated values to the store. If they ever wanted to reset those values to the Default color scheme, they could hit a reset button which would call the colorScheme reset mutation and vuex-reset would restore the initial color scheme. Check out a demo (of a different example) here:

https://vuex-reset.ianwalter.dev

I hope this article was helpful in explaining what vuex-reset is and why you would want to use it. If you find this utility useful, please star it on GitHub and consider sponsoring me!

[

ianwalter/vuex-reset

A Vuex plugin that makes restoring initial state to the store simple - ianwalter/vuex-reset

ianwalterGitHub

](https://github.com/ianwalter/vuex-reset)