bjcant.dev RSS Feed

Cancel Fetch with AbortController

Sun, 01 Dec 2019 00:00:00 GMT

If you are like me, you have wondered if there is a way to cancel a fetch request. Well, there is good news: most modern browsers now support the AbortController API, which we can use to do just that! Let’s see how it works.

AbortController is a standalone object that can interface with the fetch method. The API for AbortController is pretty simple. We can instantiate a new controller with the constructor:

const controller = new AbortController();

The controller instance has just one property, controller.signal, and one method, controller.abort(). The signal property is an object with a boolean aborted property and an abort event listener. Try this out in the console.

// check the aborted status
controller.signal.aborted
//=> false

// setup 'abort' event listener
controller.signal.onabort = () => console.log('Aborted!');

controller.abort()
// logs: 'Aborted!'

controller.signal.aborted
//=> true

First, we check the read-only aborted property, which is false by default. Calling controller.abort() flips that value to true with no way to flip it back. Once an instance of AbortController is used, we need to create a new instance to reset the value.

How does this object interface with fetch? We can pass the signal as a fetch option like so:

const controller = new AbortController();

fetch(url, { signal: controller.signal })

When we pass a signal option to fetch, it creates a listener for the abort event and will throw an error if controller.abort() is called during the DOM request or while reading the request body.

Now let’s see a working example.

We have a button that fetches a large image and sets it as the background. The fetch button becomes an abort button while the request is being made.

To see this in action, you may need to double-click pretty quickly, depending on your internet speed. The browser may cache the image after the first time it loads, so you may need to clear application storage if you want to try aborting the fetch multiple times.

Let’s walk through this code. We can start with an initial App template:

function App() {
  return (
    <div
      className="App">
      <nav>
        <button>Fetch image</button>
      </nav>
    </div>
  );
}

The idea here is to wire up the button to fetch the image, then set it as the background of the App container. Let’s see that:

function App() {
  const [url, setUrl] = useState();  const fetchData = () => {    setUrl();    return fetch("./buildings.jpg")      .then(r => r.blob())      .then(blob => setUrl(URL.createObjectURL(blob)))  };
  return (
    <div
      className="App"
      style={{backgroundImage: `url(${url})`}}    >
      <nav>
        <button onClick={fetchData}>Fetch image</button>      </nav>
    </div>
  );
}

So now the button is bound to the fetchData function, which creates a blob URL for the image and sets it to state, which in turn sets the background. Let’s add loading and error states.

function App() {
  const [url, setUrl] = useState();
  const [loading, setLoading] = useState(false);  const [error, setError] = useState(false);
  const fetchData = () => {
    setUrl();
    setError(false);    setLoading(true);    return fetch("./buildings.jpg")
      .then(r => r.blob())
      .then(blob => setUrl(URL.createObjectURL(blob)))
      .catch(e => setError(e.message))      .finally(() => setLoading(false));  };
  return (
    <div
      className="App"
      style={{backgroundImage: `url(${url})`}}
    >
      <nav>
        <button onClick={fetchData}>Fetch image</button>
      </nav>
      {loading && <div>Loading...</div>}      {error && <div>{error}</div>}    </div>
  );
}

From here, adding the abort functionality is pretty easy. We just need to add an AbortController, wire up the abort button and pass the signal to fetch!

let controller = new AbortController();const abort = () => controller.abort();
function App() {
  const [url, setUrl] = useState();
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(false);

  const fetchData = () => {
    controller = new AbortController();    setUrl();
    setError(false);
    setLoading(true);
    return fetch(
      "./buildings.jpg",
      { signal: controller.signal }    ).then(r => r.blob())
      .then(blob => setUrl(URL.createObjectURL(blob)))
      .catch(e => setError(e.message))
      .finally(() => setLoading(false));
  };
  return (
    <div className="App" style={{ backgroundImage: `url(${url})` }}>
      <nav>
        {!loading && <button onClick={fetchData}>Fetch image</button>}        {loading && <button onClick={abort}>Abort fetch</button>}      </nav>
      {loading && <div>Loading...</div>}
      {error && <div>{error}</div>}
    </div>
  );
}

You may be wondering why the controller variable is initially declared outside of the component. Remember that the controller.abort() functionality is a one-time use. Defining the controller inside the component risks object reference issues, i.e. abort() could be referencing the incorrect AbortController instance, rendering it useless. We want a fresh controller setup before every fetch, but we also need to ensure that the the abort() method is referring to the correct controller!

Conclusion

It turns out that aborting fetch requests is pretty simple with AbortController! Although the live example is in React, the concepts apply for any framework. Keep in mind that this does not work for Internet Explorer, so be sure to consider browser support before using this on production apps. For more information about AbortController, check out this article by Jake Archibald.

React and Redux without React-Redux

Thu, 31 Oct 2019 00:00:00 GMT

When bootstrapping an application using React and Redux, most of us tend to include the react-redux library, and for good reason: it contains the official React bindings for Redux. The react-redux docs to a good job at explaining why anyone would want to use it, but I don’t think many people know or understand something important:

Using React with Redux doesn’t require react-redux.

It’s true that react-redux is best-equipped to handle the interaction between Redux state and React components; after all, it’s authored by the same people. I’ve spent a lot of time dreaming up comprehensive alternatives, and they all end up looking like a less-polished version of react-redux. So why skip out on this library? For me, it comes down to one thing: boilerplate. Getting up and running with react-redux is exhausting.

With a willingness to accept some tradeoffs, we can pretty easily pull a Redux store into an app with three extra lines of code. Yep, just three lines. Take a look:

import React from 'react'
import { render } from 'react-dom'
import { createStore } from 'redux'

const reducer = (state={}, action) => { /* ...reducer logic */}
const store = createStore(reducer)

function App({ state, dispatch }) {
  return (/* ...render something */)
}

const update = () => render(  <App state={store.getState()} dispatch={store.dispatch} />,  document.getElementById('app'))store.subscribe(update)update()

One Liners - FizzBuzz

Thu, 24 Oct 2019 00:00:00 GMT

FizzBuzz is possibly the most well-known coding challenge out there. There are many flavors of this problem, but the version that most candidates see in coding interviews looks something like the description on Leet Code:

Write a program that outputs [a list of] the string representation of numbers from 1 to n.

But for multiples of three it should output “Fizz” instead of the number and for the multiples of five output “Buzz”. For numbers which are multiples of both three and five output “FizzBuzz”.

I’ve seen this problem on both sides of the interview table, and usually the JavaScript solutions are pretty standard: a for-loop wrapping if/else statements and conditionals using the uncommon modulus or remainder (i.e. %) operator. For fun, I’m going to share with you my one-liner solution and compare notes with a “regular” one in this deep-dive.

NOTE: I do not recommend doing anything like this in an interview…one-liners can be difficult to read and speak on

Review: The Regular Solution

Here is a FizzBuzz solution that I have seen so many times in so many places:

function fizzBuzz(max) {
  const result = []
  for (let i=1; i<= max; i++) {
    let str = ''

    if (i % 15 === 0) {
      result.push('FizzBuzz')
    } else if (i % 3 === 0) {
      result.push('Fizz')
    } else if (i % 5 === 0) {
      result.push('Buzz')
    } else {
      result.push(String(i))
    }
  }
  return result
}

The nice thing about this solution is that it essentially steps through the problem statement. Here are the steps of the algorithm:

Create a result array
Loop through the range of 1 to max
If the number is divisible by 3 and 5 (i.e. 15), add ‘FizzBuzz’ to the array
If the number is divisible by just 3, add ‘Fizz’ to the array
If the number is divisible by just 5, add ‘Buzz’ to the array
Default to adding the stringified number to the array of the above conditions aren’t met
Return the result

This is clean an simple, and there’s not much to optimize. Maybe a switch statement would be better than multiple else-ifs, and maybe we could find a way to combine ‘Fizz’ and ‘Buzz’ instead of handling numbers divisible by 15 separately.

The One Liner

const fizzBuzz = max => Array(max).fill().map((_,i) => String(((i + 1) % 3 === 0 ? 'Fizz' : '') + ((i + 1) % 5 === 0 ? 'Buzz' : '')) || i + 1)

Ahh, there’s nothing like horizontal scrolling on your phone to try and make sense of code. Here’s the same solution, but hopefully a bit more legible:

const fizzBuzz = max => Array(max).fill().map(
  (_,i) => String(
    (
      (i + 1) % 3 === 0 ? 'Fizz' : '')
      + ((i + 1) % 5 === 0 ? 'Buzz' : '')
    ) || i + 1
)

The Breakdown

What’s going on here? How does one arrive at a similar solution? For me, it starts with understanding the expected inputs and outputs. There is only one expected input this problem, a positive integer — that’s easy enough. If we break down the expected output to the simplest parts, we have this:

An array where each element is one of:
- ‘Fizz’
- ‘Buzz’
- ‘FizzBuzz’
- the stringified number

Part I

We know that the conditions for ‘Fizz’ and ‘Buzz’ are combined for ‘FizzBuzz’, so why not combine the actual values? That’s where we get the first bit of logic. If we want to “one-line” the if/else statements, we should use a ternary operator, which MDN illustrates as:

condition ? exprIfTrue : exprIfFalse

Let’s look back at the if/else logic for FizzBuzz, this time in the context of a function.

function fizzBuzzify(n) {
  if (i % 15 === 0) {
    return 'FizzBuzz'
  } else if (n % 3 === 0) {
    return 'Fizz'
  } else if (n % 5 === 0) {
    return 'Buzz'
  } else {
    return String(n)
  }
}

What would this logic look like with ternaries?

function fizzBuzzify(n) {
  return (
    n % 15 === 0 ? 'FizzBuzz'
    : n % 3 === 0 ? 'Fizz'
    : n % 5 === 0 ? 'Buzz'
    : String(n)
  )
}

Nested ternaries work, but they aren’t very easy to read or reason about. We can consolidate this logic further by separating the pieces. If we want to combine ‘Fizz’ and ‘Buzz’, we can do that pretty easily with string concatenation.

(n % 3 === 0 ? 'Fizz' : '') + (n % 5 === 0 ? 'Buzz' : '')

With this logic, we’ve got a few possible combinations

1. '' + ''         //=> ''
2. 'Fizz' + ''     //=> 'Fizz'
3. '' + 'Buzz'     //=> 'Buzz'
4. 'Fizz' + 'Buzz' //=> 'FizzBuzz'

From here, we can take advantage of JavaScript’s lazy evaluation feature, meaning that code won’t be executed until it is necessary. We can return n as a default value by simply adding it after the boolean OR operator (i.e. ||). If n is divisible by neither 3 nor 5, our ternary/concatenation logic will return an empty string which is falsey, and our code will fallback to n. As a final optimization, if we are always returning a string, we can wrap all of the logic in the String method. Our function now looks like this:

function fizzBuzzify(n) {
  return String(
    (n % 3 === 0 ? 'Fizz' : '')
    + (n % 5 === 0 ? 'Buzz' : '')
    || n
  )
}

Part II

Now that we tackled the if/else logic, we can turn our attention to the loop. Let’s insert our fizzBuzzify function into the original solution.

function fizzBuzz(max) {
  const result = []
  for (let i=1; i<= max; i++) {
    let str = fizzBuzzify(i)
    result.push(str)
  }
  return result
}

What would be the best way to simplify this loop into one line? We need to return an array, so we could start with an array of length max and map over that. But how to create an empty array with a given length? My first thought is to use the Array constructor. If you pass an integer as the only argument, an empty array with the given length is returned.

Array(10)
//=> [empty × 10]

There’s just one problem, we can’t operate on an empty array with map because “empty” actually means it has no value, not even undefined or null! Let’s try to return a map of the array with each index as an element.

Array(10).map((_, i) => i)
//=> [empty × 10]

As you can see, we aren’t getting what we would expect. A regular for-loop would work, but we aren’t trying to be practical here. We’re trying to be unnecessarily brief! We can literally fill every slot of the array with the .fill() method.

Array(10).fill().map((_, i) => i)
//=> [0,1,2,3,4,5,6,7,8,9]

There we go! At this point I want to make a note that there are a number of ways to create an array of a given length, but this is the fastest one-line solution that I have seen. A single loop would be the fastest of them all, but again, we’re looking for the one-lineriest solution, not the best one.

So with the original loop logic replaced by our new logic, we now have this:

function fizzBuzzify(n) {
  return String(
    (n % 3 === 0 ? 'Fizz' : '')
    + (n % 5 === 0 ? 'Buzz' : '')
    || n
  )
}

function fizzBuzz(max) {
  return Array(max).fill().map((_, i) => {
    return fizzBuzzify(i + 1)
  })
}

We pass i + 1 in the call to fizzBuzzify because our array is 0-indexed and FizzBuzz starts from 1.

Putting it All Together

The last step is putting the fizzBuzzify logic directly into the callback of .map(). For good measure, we can also replace the function declaration with an arrow function so it’s all one line.

// prettified for your viewing pleasure
const fizzBuzz = max => Array(max).fill().map(
  (_, i) => String(
    ((i + 1) % 3 === 0 ? 'Fizz' : '')
    + ((i + 1) % 5 === 0 ? 'Buzz' : '')
    || i + 1
  )
)

And that’s it!

Conclusion

Understanding method chaining and basic functional programming techniques can really help up your game as a JavaScript developer, and finding ways to write complex logic in one line can be a fun way to practice. It’s just as important to understand when to use and avoid these techniques. Maybe you can impress your friends with a one-liner FizzBuzz, but in a production or interview environment, nobody is going to to be happy about parsing all of those parentheses. Chaining methods can be very fast, but they can also be much slower than more “traditional” approaches (i.e. loops) if you aren’t careful about your choices.

If you’re interested to know the execution performance of this one-liner versus the original, you can check out the JSPerf test here. Spoiler alert: my test run showed the one-liner execute at 109 operations per second, with the original only hit 74.92 ops/sec.

I’m hoping to turn one-liners into a series, but I just need good challenges to use. If you’d like to see a one-liner deep dive on a different coding challenge, please let me know!

Refactoring Reducers with Immer

Mon, 21 Oct 2019 00:00:00 GMT

The new hotness in immutable state management is Immer, a lightweight package designed to make operating on immutable objects a breeze.

Using Immer is like having a personal assistant; he takes a letter (the current state) and gives you a copy (draft) to jot changes onto. Once you are done, the assistant will take your draft and produce the real immutable, final letter for you (the next state). - Immer

I had a lot of fun refactoring a Redux app to use Immer, so I wanted to share how easy it really is!

Here is an example of a “standard” user reducer:

const initialState = {
  meta: {
    loading: true,
    error: false
  },
  data: []
}

export default (state=initialState, action={}) => {
  switch (action.type) {
    case 'USERS_LOAD':
      return {
        ...state,
        meta: {
          ...state.meta,
          loading: true,
          error: false
        }
      }
    case 'USERS_LOAD_SUCCESS':
      return {
        ...state,
        data: [...action.payload.data],
        meta: {
          ...state.meta,
          loading: false,
          error: false
        }
      }
    case 'USERS_LOAD_FAILURE':
      return {
        ...state,
        meta: {
          ...state.meta,
          loading: false,
          error: action.payload.error
        }
      }
    default:
      return state
  }
}

This should seem very familiar. We have a function that accepts the current state and an action as arguments and returns a new state copy with alterations based on action.type and an optional action.payload. We see a lot of object rest spreads (i.e. the ellipses or ...), which can become verbose and error-prone when we get into larger nested structures. One could argue that each state managed by a reducer should have a flat data structure, but in practice that is a rare occurrence.

Immer allows us to simplify this pattern by operating on a draft copy of the state as if it is mutable. To see what that looks like, let’s refactor this reducer.

First, will import the produce function and put the reducer and initialState in as the arguments of the produce call.

import produce from 'immer'
const initialState = {
  meta: {
    loading: true,
    error: false
  },
  data: []
}

export default produce(  (state, action={}) => {    switch (action.type) {
      case 'USERS_LOAD':
        return {
          ...state,
          meta: {
            ...state.meta,
            loading: true,
            error: false
          }
        }
      case 'USERS_LOAD_SUCCESS':
        return {
          ...state,
          data: [...action.payload.data],
          meta: {
            ...state.meta,
            loading: false,
            error: false
          }
        }
      case 'USERS_LOAD_FAILURE':
        return {
          ...state,
          meta: {
            ...state.meta,
            loading: false,
            error: action.payload.error
          }
        }
      default:
        return state    }  },   initialState
)

Next, we’re going to rename state to draft. This is just so we can stick with the Immer’s concept of manipulating a “draft state”. For more context, check out the Immer docs.

import produce from 'immer'

const initialState = {
  meta: {
    loading: true,
    error: false
  },
  data: []
}

export default produce(
  (draft, action={}) => {    switch (action.type) {
      case 'USERS_LOAD':
        return {
          ...draft,          meta: {
            ...draft.meta,            loading: true,
            error: false
          }
        }
      case 'USERS_LOAD_SUCCESS':
        return {
          ...draft,          data: [...action.payload.data],
          meta: {
            ...draft.meta,            loading: false,
            error: false
          }
        }
      case 'USERS_LOAD_FAILURE':
        return {
          ...draft,          meta: {
            ...draft.meta,            loading: false,
            error: action.payload.error
          }
        }
      default:
        return draft    }
  }, 
  initialState
)

In order to manipulate state within the produce function, we just need to identify the changes we actually want to make. Let’s take the first original switch case as an example:

case 'USERS_LOAD':
  return {
    ...state,
    meta: {
      ...state.meta,
      loading: true,
      error: false
    }
  }

What values are really changing? Just state.meta.loading and state.meta.error.

With Immer, we can represent these changes by simply operating on the draft state like it is mutable and the produce function will return a read-only copy without us needing to explicitly return anything.

case 'USERS_LOAD':
  draft.meta.loading = true
  draft.meta.error = false
  return

Since we don’t need to return any data within the produce callback, we can skip the default case too. The entire refactor will look like this:

import produce from 'immer'

const initialState = {
  meta: {
    loading: true,
    error: false
  },
  data: []
}

export default produce(
  (draft, action={}) => {
    switch (action.type) {
      case 'USERS_LOAD':
        draft.meta.loading = true
        draft.meta.error = false
        return
      case 'USERS_LOAD_SUCCESS':
        draft.data = action.payload.data
        draft.meta.loading = false
        draft.meta.error = false
        return
      case 'USERS_LOAD_FAILURE':
        draft.meta.loading = false
        draft.meta.error = action.payload.error
        return
    }
  }, 
  initialState
)

The draft is actually a proxy of the current state. Based on the changes to the draft, Immer will determine which parts of the state can be re-used and which require a new copy.

Conclusion

What do you think? Does this look better or worse, simpler or more more complex? To me, this is definitely a smaller, more concise reducer. If you want to learn more about this approach, I recommend checking out the curried produce section of the Immer docs.

JS Numeric Separator

Sat, 19 Oct 2019 00:00:00 GMT

Here’s a new ECMAScript feature that I am excited about: numeric separators. Currently in proposal stage 3, this readability feature will make it much easier for our eyes to parse numbers. If you have Chrome version 75 or above — find your version by typing chrome://version/ in your URL input — you can test out this feature in Chrome dev tools right now!

// try this in the console
let oneMillion = 1_000_000

The underscore can be place between any numeric values, including after a decimal.

let pi = 3.141_592_653

You may notice that the actual numeric value omits the separator. Don’t get too attached!

pi
//=> 3.141592653

This is especially useful for separating binary numbers.

let binary = 0b1101_1100_0000

It also works for hexadecimal…

let abc = 0xA_B_C

BigInt…

let frickinHugeInt = 1_000_000_000_000_000_000_000n

… and exponential notation!

let infinitePi = 3.145e1_000

Separators can be placed in unconventional places, too.

let kwazyInt = 43_8_83998_123_583_1_0

Not sure why you would want to do that 🤷‍.

There are some limitations to the separator. These are the things you can’t do:

Place underscores at the beginning or end of a number

// no
_1000

// nope
1000_

Place underscores adjacent to a non-numeric character

// nah
1_.348

// also nah
5.43_e2

Place underscores adjacent to each other

// nice try
1__000__000

Remember, this feature is still in proposal phase and as of this writing is not available on browsers other than Chrome. For Node apps, you will need to be running on v12.5 or higher. If you want to use this on the web, your only viable option for now is to transpile your JS with Babel, unless of course you are confident that all of your users are on the latest Chrome 😜. Gotta keep ‘em separated!

Composing Styles with Tachyons and CSS Modules

Wed, 16 Oct 2019 00:00:00 GMT

For a while now, I have used CSS modules to style applications at work. If you have never used CSS modules before, it can be a great solution for scoped, composable styles. Building a shared component library? CSS Modules will be your friend!

My team started working on a project that couples CSS modules with Tachyons, a small open-source CSS library of utility classes. If you are familiar with TailwindCSS, Tachyons is comparable but much more simple. Contrary to most style patterns, utility-based CSS libraries like Tachyons discourage the use of the cascade, preferring instead to use class names that describe the style property and value.

Using an example of a heading:

<h1 class="f3 f2-m f1-l fw2 black-90 mv3">
  This is the title
</h1>

Each class represents a single style. The Tachyons design system is mobile-first, so f3 represents the third largest font-size by default, while f2-m and f1-l represent increasing font-sizes for medium and large screens, respectively. fw2 is the second-largest font-weight, mv3 the third-largest vertical margin (top and bottom), and black-90 is simply a black text color with .9 opacity. The condensed names can take a while to get used to, but there are some nice lookup tools like tachyons-tldr.

You may be able to see some drawbacks of this already. For me, there are two big ones:

It’s repetitive: Want the text-color to be rgba(0,0,0,.9) for all copy? Every tag needs the class name!
It’s verbose: If one tag requires some complex styling, you will be looking at a long line of class names. This is particularly apparent with media queries, as with the font-size above (i.e. f3 f2-m f1-l).

Combine Tachyons with CSS Modules and you have a solution to both of these problems: class name composition! I want to take you through my approach to this pattern using Webpack.

Things we will learn:

How to setup a webpack config for CSS Modules
How to integrate the Tachyons library into your project
How to compose styles
How to use PostCSS to avoid @import pitfalls
How to alias filepaths in composes rules

Setup the project

We’re going to build a simple profile-card component from the Tachyons component library. Let’s get started by creating a new project with subfolders.

If you want to skip the file creation and go straight to code, you can clone the starter repo.

mkdir -p css-modules-tachyons-demo/{src,dist,vendors}
cd css-modules-tachyons-demo && npm init --yes

Now we’ll include webpack and the basic loaders and plugins to build a single page application.

npm install --save-dev webpack webpack-cli webpack-dev-server \
  html-webpack-plugin css-loader style-loader

We’re going to include tachyons-custom — a fork of the main Tachyons library with all variables definitions in a single file — and move the source into our /vendors folder.

npm install --save-dev tachyons-custom
cp -r node_modules/tachyons-custom/src/ vendors/tachyons/

Why copy all of the source files over? The Tachyons team recommends it. Tachyons is meant to be overridden and extended (via CSS variables or otherwise).

Almost ready to write some code! Just need to add a few files:

touch index.html webpack.config.js src/index.js src/styles.css

Initial template

Let’s start with a simple template.

<!-- index.html -->
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title><%= htmlWebpackPlugin.options.title %></title>
  </head>

  <body>
    <div id="app"></div>
  </body>
</html>

// src/index.js
import '../vendors/tachyons/tachyons.css';

document.getElementById('app').innerHTML = `
  <article class="mw5 center bg-white br3 pa3 pa4-ns mv3 ba b--black-10">
    <div class="tc">
      <img 
        src="http://tachyons.io/img/avatar_1.jpg" 
        class="br-100 h4 w4 dib ba b--black-05 pa2" 
        title="Photo of a kitty staring at you"
      >
      <h1 class="f3 mb2">Mimi W.</h1>
      <h2 class="f5 fw4 gray mt0">CCO (Chief Cat Officer)</h2>
    </div>
  </article>
`;

Build configuration

We’re going to add the basic webpack config,

// webpack.config.js
const path = require('path');
const htmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
  module: {
    rules: [{
      test: /\.css$/,
      use: [
        'style-loader',
        'css-loader',
      ]
    }]
  },
  plugins: [
    new htmlWebpackPlugin({
      title: 'CSS Modules + Tachyons',
      template: 'index.html'
    })
  ]
}

and add the build and serve scripts in package.json.

{
  "scripts": {
    "start": "webpack-dev-server",
    "build": "webpack"
  }
}

Now, we should be able to run the app and see the styled profile card!

npm start

The gotcha

Wait…EVERYTHING BROKE…what just happened?

You’re probably seeing about two-dozen errors that look something like this:

ERROR in ./vendors/tachyons/tachyons.css (./node_modules/css-loader/dist/cjs.js!./vendors/tachyons/tachyons.css)
Module not found: Error: Can't resolve './_aspect-ratios' in '/Users/<user>/code/css-modules-tachyons-demo/css-modules-tachyons-demo/vendors/tachyons'
 @ ./vendors/tachyons/tachyons.css (./node_modules/css-loader/dist/cjs.js!./vendors/tachyons/tachyons.css) 5:10-81
 @ ./vendors/tachyons/tachyons.css
 @ ./src/index.js

Take a look at vendors/tachyons/tachyons.css. What do you notice? There are no styles defined in that file! Instead, it is full of @import statements. When css-loader is looking at tachyons.css, it doesn’t look any deeper to process imported modules. To get module composition to play nice with @import, we need to bring PostCSS into our build process. Let’s install 3 more packages.

npm install --save-dev postcss postcss-loader postcss-import

Now, we need to create a config file for postcss and add postcss-loader to our Webpack config.

touch postcss.config.js

// postcss.config.js
module.exports = {
  plugins: [
    require('postcss-import')()
  ]
}

postcss-import processes inlines @import statements. We need that to run before css-loader, so we’re going to modify the CSS rule.

// webpack.config.js
{
  test: /\.css$/,
  use: [
    'style-loader',
    {      loader: 'css-loader',      options: {        importLoaders: 1      }    },    'postcss-loader'  ]
}

The importLoaders option tells css-loader how many loaders to run before css-loader executes. We want postcss-import to process all the @import statements, then interpret the CSS Modules.

Since we updated the Webpack config, we need to kill the local server and run it again. Everything should be working again!

Turn on CSS Modules

Ok, now for the fun part! We’re going to update our css-loader options to allow CSS modules, then refactor.

In webpack.config.js, update the CSS rule again.

{
  test: /\.css$/,
  use: [
    'style-loader',
    {
      loader: 'css-loader',
      options: {
        importLoaders: 1,
        modules: {          localIdentName: '[name]__[local]',        },      }
    },
    'postcss-loader'
  ]
}

This enables the modules option and renames all imported CSS classes to the specified pattern. In this case [name] is the filename the style is imported from, and [local] is the actual class name.

Now, we’re going to refactor the profile card markup to use a single class name reference for each tag. In index.js, change the import to point to our local CSS file.

// index.js
import styles from './styles.css';

document.getElementById('app').innerHTML = `
  <article class="${styles.profileCard}">
    <div class="${styles.profileCardBody}">
      <img 
        src="http://tachyons.io/img/avatar_1.jpg" 
        class="${styles.profileCardImage}" 
        title="Photo of a kitty staring at you"
      >
      <h1 class="${styles.profileCardTitle}">Mimi W.</h1>
      <h2 class="${styles.profileCardSubtitle}">CCO (Chief Cat Officer)</h2>
    </div>
  </article>
`;

If you run the app and inspect the page, we should see that the app isn’t styled and all of the tags have class="undefined". Why would that be? With CSS Modules turned on, we can import a styles object from ./styles.css. Since styles.css is empty, so is the styles object! Let’s try adding a style.

/* src/styles.css */
.profileCard {
  max-width: 3rem;
  margin-left: auto;
  margin-right: auto;
}

Inspect the app now, and you should see the styles applied, along with a new class name.

<article class="styles_profileCard">...</article>

Composition

With CSS Modules, we can compose class selectors with a special composes rule. Let’s try composing the styles we just added to .profileCard.

/* src/styles.css */
.mw3 { max-width: 3rem; }
.center { 
  margin-left: auto;
  margin-right: auto;
}

.profileCard {
  composes: mw3 center;
}

As you can see, multiple classes can be added to a single composes rule by space-separating them. For more detail on composition syntax, checkout the CSS Modules docs.

If we want to compose classes directly from Tachyons, we can import the CSS file first:

/* src/styles.css */
@import '../vendors/tachyons/tachyons.css';

.profileCard {
  composes: mw3 center;
}

We have to be careful about this approach. In the context of our little demo this may suffice, but for a full-fledged application this could result in duplicate generation of the Tachyons library. Instead, we can compose classes directly from Tachyons.

/* src/styles.css */
.profileCard {
  composes: mw3 center from '../vendors/tachyons/tachyons.css';
}

Refactor

Now, let’s refactor the styles for the rest of the component to use class name composition. For reference, here are the class mappings

Module class	Tachyons classes
.profileCard	mw5 center bg-white br3 pa3 pa4-ns mv3 ba b—black-10
.profileCardBody	tc
.profileCardImage	br-100 h4 w4 dib ba b—black-05 pa2
.profileCardTitle	f3 mb2
.profileCardSubtitle	f5 fw4 gray mt0

The pattern will look like this:

[module_class]: {
  composes: [tachyons_classes] from '../vendors/tachyons/tachyons.css';
}

When all is said and done, our styles.css should look like this:

/* src/styles.css */
.profileCard { 
  composes: mw5 center bg-white br3 pa3 pa4-ns mv3 ba b--black-10 from '../vendors/tachyons/tachyons.css';
}
.profileCardBody { 
  composes: tc from '../vendors/tachyons/tachyons.css';
}
.profileCardImage { 
  composes: br-100 h4 w4 dib ba b--black-05 pa2 from '../vendors/tachyons/tachyons.css';
}
.profileCardTitle { 
  composes: f3 mb2 from '../vendors/tachyons/tachyons.css';
}
.profileCardSubtitle { 
  composes: f5 fw4 gray mt0 from '../vendors/tachyons/tachyons.css';
}

Looking good! Our profile card should look just as it did before, with all of the Tachyons class names applied to each tag. The only thing I don’t like here is the repetitive filepath to tachyons.css.

Clean up

This is the bonus round! At this point we have gone through everything necessary to develop an app using this pattern. Feel free to either stop here or keep trucking!

There are two quick ways that we can clean up the reference to the tachyons.css file. First, we can define a variable using the special @value from CSS Modules, which css-loader supports out of the box.

/* src/styles.css */
@value tachyons: '../vendors/tachyons/tachyons.css';

.profileCard { 
  composes: mw5 center bg-white br3 pa3 pa4-ns mv3 ba b--black-10 from tachyons;
}
.profileCardBody { 
  composes: tc from tachyons;
}
.profileCardImage { 
  composes: br-100 h4 w4 dib ba b--black-05 pa2 from tachyons;
}
.profileCardTitle { 
  composes: f3 mb2 from tachyons;
}
.profileCardSubtitle { 
  composes: f5 fw4 gray mt0 from tachyons;
}

This looks nicer, but there are still a couple issues. For one, the @value statement will need to be repeated in every file that references Tachyons, and the relative filepath is subject to change. Also, there is a risk that the variable name can conflict with strings, which will break things if you mix and match @value variables and filepaths in composes rules.

Instead, I prefer to use Webpack’s alias feature. We can define an alias name for Tachyons that will always resolve to the same place, no matter where it is imported from.

In the top level of the Webpack config, add a resolve property.

// webpack.config.js
const path = require('path');
const htmlWebpackPlugin = require('html-webpack-plugin');
module.exports = {
  module: {
    rules: [{
      test: /\.css$/,
      use: [
        'style-loader',
        {
          loader: 'css-loader',
          options: {
            modules: {
              localIdentName: '[name]__[local]',
            },
            importLoaders: 1
          }
        },
        'postcss-loader'
      ]
    }]
  },
  resolve: {    alias: {      tachyons$: path.resolve(__dirname, 'vendors/tachyons/tachyons.css')    }  },  plugins: [
    new htmlWebpackPlugin({
      title: 'CSS Modules + Tachyons',
      template: 'index.html'
    })
  ]
}

If your local server is still running, remember to kill it and restart.

This will allow us to import directly from tachyons instead of needing the whole path. The $ is for an exact match. With this config, you’d still need to add the whole filepath if you want to import from a different file within vendors/tachyons/. Now our styles.css can look squeaky clean!

/* src/styles.css */
.profileCard { 
  composes: mw5 center bg-white br3 pa3 pa4-ns mv3 ba b--black-10 from '~tachyons';
}
.profileCardBody { 
  composes: tc from '~tachyons';
}
.profileCardImage { 
  composes: br-100 h4 w4 dib ba b--black-05 pa2 from '~tachyons';
}
.profileCardTitle { 
  composes: f3 mb2 from '~tachyons';
}
.profileCardSubtitle { 
  composes: f5 fw4 gray mt0 from '~tachyons';
}

The tilde (”~”) prefix tells css-loader to look for an alias or in node_modules for a package.

Dark mode

Of course, we aren’t reaping the benefits of this design pattern if we don’t try changing some things around. Let’s change the color scheme to use a dark mode!

Let’s add a background color to html and tweak some of the color classes.

/* src/styles.css */
html {
  background: #222;
}

.profileCard {  composes: sans-serif mw5 center bg-near-black br3 pa3 pa4-ns mv3 ba b--white-30 shadow-5 near-white from '~tachyons';}
.profileCardBody {
  composes: tc from '~tachyons';
}

.profileCardImage {  composes: br-100 h4 w4 dib ba b--white-20 bg-dark-pink pa2 from '~tachyons';}
.profileCardTitle {
  composes: f3 mb2 from '~tachyons';
}

.profileCardSubtitle {  composes: f5 fw4 white-60 mt0 from '~tachyons';}

All of the available colors are in vendors/tachyons/_variables.css. Play around and see what you come up with! Once you get used to the class name patterns, changing styles is effortless

Conclusion

Thanks for reading! To see the finished product, clone the starter repo and checkout the complete branch.

I hope this post has convinced you to try combining CSS Modules and Tachyons (or any utility-based CSS library, really) for your next project! If you have any questions/comments, drop me a line!

Welcome!

Sat, 12 Oct 2019 00:00:00 GMT

Welcome to my new site, bjcant.dev! This will be the new home of my writings on web development, particularly in the front-end space. My old website, https://bjcantlupe.com, will remain up as an archive of posts and projects from the beginning of my career in technology. Someday it will be repurposed, but for now I like it as a friendly reminder of what it took to get where I am today.

what’s the deal with this site?

After taking a two-year “hiatus” (*cough*-lazy-*cough*), I am finally following through with a personal goal to give back to the dev community. Not only do I want to share what I have learned while working as a web developer, but I also recognize that participating in the dev community is one of the best ways to learn.

So I want to start by talking about this site. The goal was to create something with a single purpose, free of distractions — just a blog. I wanted to build it in a weekend, and that’s exactly what happened! It’s a work in progress, but as I have learned: everything is a work in progress. I will add related posts along with new features and improvements.

A few things on the TODO list:

Refactor CSS to utilize CSS modules
Refactor template file structure
Add light mode (I guess)
Update SEO stuff
Add a “read time” feature, a la Medium
Cross-post to Dev.to via RSS feed

This site was built using Gatsby.js, the insanely popular static site generator backed by React and GraphQL. It was bootstrapped using gatsby-starter-blog and styled with the tachyons-verbose CSS library. The color palette was pseudo-generated from somewhere I can’t remember. I chose to start with a dark theme because frankly, light backgrounds give me headaches. The site is hosted on Netlify, which is easily the quickest and smoothest deployment pipeline setup I have ever gone through.

what’s next?

More posts! I am challenging myself to write at least two posts a week — we’ll see how that goes. If you’d like to learn more about me and/or get in touch, I’d love to hear from you! I can be found on LinkedIn, twitter, or email