DEV Community: Saul Hardman

A Word of Caution Regarding Cross-Posting To DEV

Saul Hardman — Fri, 28 Aug 2020 12:39:57 +0000

I cross-post all of my articles to DEV (soon to other platforms such as Medium and Hashnode as well) and am very happy to do so.

DEV provides the ability to set a <link rel="canonical"> pointing to the original article's permalink on the viewsource.io domain. Up until now this appears to have worked just fine with Google ranking my domain higher in the results than dev.to (if DEV is there at all).

However, my latest article seems to have fallen between the gaps somewhere as the DEV version of the article is the only one which displays in the search results for the search term "Managing access tokens with GitHub Actions":

The original article only appears in the search results if I navigate to the final page of results and click the 'search with the omitted results included' link:

Despite both pages containing a rel="canonical" link pointing to the same page, the original article appears to be falling foul of Google's duplicate content filters.

This is either an anomaly or (as I suspect) this has happened due to the DEV article being crawled and indexed before my site, meaning that the href attribute of the <link rel="canonical"> was to a page that was not indexed.

Given the drastic differences in the size of the 2 sites it's not unreasonable to presume DEV simply has a larger crawl budget and is indexed far faster than my one-person publication.

In order to avoid this outcome in the future I'm planning to adopt the policy of waiting at least a few days before cross-posting my articles.

What do you think DEV community? Is my theory sound? Those of you who cross-post: have you been bitten by this before? Do you cross-post immediately or wait some time?

Managing Access Tokens with GitHub Actions and Encrypted Secrets

Saul Hardman — Wed, 12 Aug 2020 16:15:06 +0000

Integrating 3rd-party APIs into Jamstack apps and websites becomes a bit tricky when the access tokens for these services need refreshing recurrently. Manually refreshing these access tokens and updating the corresponding secrets is one option, but automating the process via a scheduled GitHub Workflow—though adding complexity—gives you one less thing to worry about. Using the Instagram Basic Display API as a basis, I'm going to walk-through an example of automating this process.

Create an Encrypted Secret

The first step is to add an existing (valid) access token to your repository as an encrypted secret. It appears to be a convention to use UPPER_CASE_SNAKE_CASE when naming these secrets, so I've assigned my access token for the Instagram Basic Display API to a secret named INSTAGRAM_ACCESS_TOKEN.

Pass a Secret as an Environment Variable

The context in which I'll be using this access token within my Jamstack website is an axios request querying the Instagram User Media endpoint, e.g.:

const response = await axios.get(
  `https://graph.instagram.com/${instagramUserId}/media`,
  {
    params: {
      access_token: process.env.INSTAGRAM_ACCESS_TOKEN,
      fields: options.fields.join(",")
    }
  }
);

For process.env.INSTAGRAM_ACCESS_TOKEN to be referencing the correct value at runtime the environment variable INSTAGRAM_ACCESS_TOKEN must be present at build time. As part of a Continuous Deployment workflow, I assign the encrypted secret INSTAGRAM_ACCESS_TOKEN as an environment variable (of the same name) to the build step:

# .github/workflows/deploy.yml
name: Continuous Deployment

on:
  push:
    branches:
      - master

jobs:
  deploy:
    timeout-minutes: 5

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - uses: actions/setup-node@v1
        with:
          node-version: 12

      - uses: bahmutov/npm-install@v1

      - run: yarn build
        env:
          NODE_ENV: production
          INSTAGRAM_ACCESS_TOKEN: ${{ secrets.INSTAGRAM_ACCESS_TOKEN }}

Create a Scheduled Workflow

Long-lived Instagram access tokens will last 3 months, but must be refreshing within 2 months of the date they're issued. If we forget to update the INSTAGRAM_ACCESS_TOKEN secret on this repository within that time the yarn build command will fail. To prevent this from happening we can create an additional GitHub Workflow that refreshes the Instagram access token and updates the corresponding repository secret on a schedule.

In a "here's one I made earlier" fashion, I've already created GitHub Actions for refreshing Instagram access tokens and updating GitHub secrets. Be sure to follow the installation instructions in those packages' respective READMEs. One thing to note is that a Personal Access Token (PAT) with the 'repo' scope is required to create or update GitHub Secrets via the GitHub API.

With the action packages installed and a PAT set to a secret named PERSONAL_ACCESS_TOKEN we can now setup a scheduled GitHub Workflow:

# .github/workflows/instagram.yml
name: Refresh Instagram Access Token & Update GitHub Secret

on:
  schedule:
    # https://crontab.guru/#0_0_1_*_*
    - cron: "0 0 1 * *"

jobs:
  instagram:
    steps:
      - uses: actions/checkout@v2

      - uses: actions/setup-node@v1
        with:
          node-version: 12

      - uses: bahmutov/npm-install@v1

      - name: Refresh Instagram Access Token
        id: instagram
        uses: ./node_modules/@saulhardman/refresh-instagram-access-token
        with:
          access_token: ${{ secrets.INSTAGRAM_ACCESS_TOKEN }}

      - name: Update GitHub Secret
        uses: ./node_modules/@saulhardman/update-github-secret
        with:
          secret_name: INSTAGRAM_ACCESS_TOKEN
          secret_value: ${{ steps.instagram.outputs.access_token }}
          access_token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}

An bonus step that I often include in workflows like these is to send a Pushover notification on success or failure. Passing the access token as part of the success payload gives me the opportunity to update my local development .env file, too.

A Note on Netlify

As far as I'm aware, Netlify doesn't have an API for managing environment variables (in the free tier, at least). If your project is private and you live life fast and dangerous you could read and write an access token from and to a .env file that you then commit back to the repository:

- uses: falti/dotenv-action@v0.2.4
  id: dotenv

- name: Refresh Instagram Access Token
  id: instagram
  uses: ./node_modules/@saulhardman/refresh-instagram-access-token
  with:
    access_token: ${{ steps.dotenv.outputs.instagram_access_token }}

- uses: TickX/var-to-dotenv@v1.1.1
  with:
    key: INSTAGRAM_ACCESS_TOKEN
    value: ${{ steps.instagram.outputs.access_token }}
    default: ${{ steps.dotenv.outputs.instagram_access_token }}

- name: Commit Updated DotEnv
  uses: EndBug/add-and-commit@v4
  with:
    message: "chore: refresh instagram access token"
    add: .env
  env:
    GITHUB_TOKEN: ${{ github.token }}

Local Testing

I often develop new Workflows on a feature branch and configure them to run on push until they're ready to be merged into the primary branch. A less cumbersome option is to use act to debug Workflows locally.

Closing Thoughts

Automation can be a double-edged sword, but for processes like this GitHub Workflows are a blessing for a front-end web developer working with the Jamstack. How do you manage access tokens? How are you using GitHub Actions to extend the Jamstack?

Publishing and Installing Private GitHub Packages using Yarn and Lerna

Saul Hardman — Tue, 19 May 2020 14:44:42 +0000

I have a collection of snippets and utilities that I frequently reach for when building web stuff. Up until now this code has been managed in a very adhoc fashion – copied and pasted between codebases, un-versioned, and free from the burden of tests 😉

The temptation is to publish these utilities, collectively or individually, on a package registry such as NPM. But, as rewarding and exhilarating as it can be to open source code, it does have its downsides. In particular, publicly publishing a package can signal to other developers that it's production-ready and bring with it the apparent obligation of supporting its use. Alternatively, sometimes the code is sensitive in nature or is not yet mature enough to see the light of day.

Publishing these packages privately is a good solution so long as it's economical and has an efficient enough workflow. To keep the organisational overhead low I'll keep them all in a single repository, following the monolithic repository pattern. (I can't help but feel "minilithic" would be a more appropriate name here.)

NPM doesn't allow users to publish private packages for free, but the GitHub Package Registry does (with strings attached). Given GitHub's recent acquisition of NPM this might well change in the future 🤷‍♂️

Setup the Mono-Repository

I'll use my nuxt-modules private GitHub repository, and the private packages within, as a working example.

Let's get started... In a terminal of your choice create a new project directory and initialise Git and Yarn:

> mkdir nuxt-modules
> cd nuxt-modules
> git init
> yarn init

Enable Yarn Workspaces by configuring the "workspaces" property in package.json:

{
  "name": "nuxt-modules",
  "private": true,
  "workspaces": ["packages/*"]
}

Initialise Lerna with independent versioning enabled:

> lerna init --independent

Configure Lerna to play-nice with Yarn Workspaces and target the GitHub Package Registry in lerna.json:

{
  "packages": ["packages/*"],
  "version": "independent",
  "npmClient": "yarn",
  "useWorkspaces": true,
  "command": {
    "publish": {
      "conventionalCommits": true,
      "message": "chore(release): publish",
      "registry": "https://npm.pkg.github.com",
      "allowBranch": "master"
    }
  }
}

Feel free to customise the other properties, these are just my preferences.

Create the Packages

Populate the packages/ directory with a sub-directory for each package. The directory names shouldn't be prefixed with the scope, but the name field in the package.json should, e.g. packages/nuxt-html-validate will contain a package.json with the name field set to @saulhardman/nuxt-html-validate.

You can create packages using Lerna's lerna create command or by hand. The bare-minimum for an NPM package is a JavaScript entry-point (e.g. index.js) and a package.json.

Development dependencies that are common to all of the packages should be installed in the mono-repository root. As an example, here's the command to install ESLint, passing the -W argument to the add command:

> yarn add --dev -W eslint

A critical step in this process is to run yarn init within each of the directories. It's then necessary to make a minor adjustment to the resulting package.json files to set the repository.directory and publishConfig.registry fields. Here is an example of the @saulhardman/nuxt-html-validate package which is located in the packages/nuxt-html-validate/ sub-directory:

{
  "repository": {
    "type": "git",
    "url": "ssh://git@github.com/saulhardman/nuxt-modules.git",
    "directory": "packages/nuxt-html-validate"
  },
  "publishConfig": {
    "registry": "https://npm.pkg.github.com/"
  }
}

The final result should look something like this:

.
├── .gitignore
├── LICENSE.md
├── lerna.json
├── package.json
├── packages
│   ├── nuxt-html-validate
│   │   ├── README.md
│   │   ├── index.js
│   │   └── package.json
│   ├── nuxt-release
│   │   ├── README.md
│   │   ├── index.js
│   │   └── package.json
│   ├── nuxt-robotize
│   │   ├── README.md
│   │   ├── index.js
│   │   └── package.json
│   └── nuxt-rss
│       ├── README.md
│       ├── index.js
│       └── package.json
└── yarn.lock

Authenticate with the GitHub Package Registry

The next step is to authenticate with the Github Package Registry (replace @saulhardman with your GitHub username):

> npm login --registry=https://npm.pkg.github.com --scope=@saulhardman

To interact with the package repository API, GitHub requires you to create a Personal Access Token (PAT) which you will use in-lieu of your password. Make sure that the 'repo', 'write:packages', 'read:packages', and 'delete:packages' options are selected:

With that in-hand the .npmrc is configured to point requests for @saulhardman-scoped packages to GitHub (rather than NPM) and provide the PAT as an authToken (replace TOKEN and @saulhardman with your respective values):

//npm.pkg.github.com/:_authToken=TOKEN
@saulhardman:registry=https://npm.pkg.github.com

Even though this Git repository will be private it's good practice not to commit keys and tokens. Accordingly, be sure to amend the .gitignore config to include the .npmrc.

Publish the Packages

Create your private GitHub repository and push your initial commit containing your packages. It's my preference to set the package.version fields to 0.0.0 to begin with. At publish-time you can pass minor or major to have 0.1.0 or 1.0.0 be the initial release version:

> yarn lerna publish minor # initial release 0.1.0
> yarn lerna publish major # initial release 1.0.0

Once you've received a "Package published" response, you will be able to view your packages on the GitHub repository page:

Installing Private GitHub Packages

The permissions workflow surrounding private packages is... not great. There is, as far as I'm aware, no way to scope PATs to organisations, repositories, or packages. The method outlined here will allow you to install all private packages that your GitHub account has access to.

To install a private package all that's required is an .npmrc to assign an access token and configure the scopes. The PAT could be the same one used above or a different PAT with read-only permissions (replace TOKEN with your PAT and @saulhardman with your GitHub username):

//npm.pkg.github.com/:_authToken=TOKEN
@saulhardman:registry=https://npm.pkg.github.com

Only packages in the scope @saulhardman will be installed from the GitHub Package Registry – all others will default to NPM. The yarn add command can be used as usual, e.g.:

> yarn add @saulhardman/nuxt-html-validate

Installing Private GitHub Packages from GitHub Actions

Setting the NODE_AUTH_TOKEN environment variable on the yarn install step should be enough, but in my experience it is not. There is a thread on the GitHub Community Forum documenting a number of people's struggles.

An alternative – whether you're running yarn install directly or using a third-party action such as bahmutov/npm-install – is to construct an .npmrc dynamically using a PAT stored as an encrypted secret:

steps:
  - name: Configure NPM
    run: |
      echo "//npm.pkg.github.com/:_authToken=$NODE_AUTH_TOKEN" > .npmrc
      echo '@saulhardman:registry=https://npm.pkg.github.com' >> .npmrc
    env:
      NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}

  - name: Install Yarn Dependencies
    uses: bahmutov/npm-install@v1

Closing Thoughts

I've created a number of private packages over the last few months – ranging from the Nuxt modules outlined above to Vue components and JavaScript utilities. I've thoroughly enjoyed it so far and I feel the initial overhead will be well worth the reward in the long term.

Discovering a bug in one usage context, fixing it, adding a test case if necessary, and then having that update trickle-down to other projects with very little friction is both satisfying and refreshing.

Additional Resources

Generate a Critical JavaScript Bundle Using Rollup

Saul Hardman — Fri, 21 Feb 2020 15:52:00 +0000

For performance and user experience reasons there are certain tasks that we want to complete before DOM content, stylesheets, or scripts have loaded. Critical JavaScript, inlined into <script> blocks in the <head> of an HTML document, is a pattern for achieving this:-

<!DOCTYPE html>
<html>
  <head>
    <script>
      console.log("I am critical!");
    </script>
  </head>
</html>

Examples of such tasks include running CSS and JavaScript feature tests, loading polyfills, and performing conditional logic.

Keep Things Simple

Given that Critical JavaScript is inlined directly into the <head> of every HTML response, it's essential that we keep the bundle size small.

A step towards this is keeping the code simple with respect to the JavaScript and DOM APIs used and in-turn disabling transpilation tools from doing anything other than syntax transformation (see below for instructions on how to configure Babel).

Configuring Browserslist to reflect your support matrix will allow for the use of complimentary tools such as eslint-plugin-compat to ensure that you're not using unsupported features in production.

All of this means you can leverage modern ES6 syntax such as Arrow Functions, but omit JavaScript APIs such as Promises and DOM APIs like Element.classList. However, the syntax and features available to you are entirely dependent on your own browser support matrix.

If polyfilling a feature is unavoidable then I would recommend doing so by directly importing specific modules from core-js.

Why Rollup

There’s no 2-ways about it: Rollup creates bundles that are simpler and smaller than those created by alternatives such as Webpack.

The following is a starting point for how to best configure Rollup to output critical.js bundles with the smallest footprint:-

// rollup.config.js
import path from "path";

import resolve from "@rollup/plugin-node-resolve";
import commonJs from "@rollup/plugin-commonjs";
import replace from "@rollup/plugin-replace";
import babel from "rollup-plugin-babel";
import { terser } from "rollup-plugin-terser";
import filesize from "rollup-plugin-filesize";

const { NODE_ENV = "development" } = process.env;

const isProduction = NODE_ENV === "production";
const ANALYZE = process.env.ANALYZE ? process.env.ANALYZE === "true" : false;

export default {
  input: path.join(process.cwd(), "critical.js"),

  output: {
    dir: path.join(process.cwd(), "critical.min.js"),
    format: "iife",
    sourcemap: isProduction ? false : "inline"
  },

  plugins: [
    replace({
      "process.env.NODE_ENV": JSON.stringify(NODE_ENV)
    }),

    resolve({
      browser: true
    }),

    commonJs({
      include: "node_modules/**"
    }),

    babel({
      exclude: "node_modules/**",
      babelrc: false,
      presets: [
        [
          "@babel/preset-env",
          {
            debug: ANALYZE,
            modules: false,
            useBuiltIns: false
          }
        ]
      ]
    }),

    isProduction && terser(),

    isProduction && filesize()
  ].filter(Boolean)
};

Below is just an example of some of the tasks that you might perform via critical.js. It's by no means comprehensive, but it's a good example of the purpose of this category of JavaScript bundle.

// critical.js
// polyfill asynchronously loading CSS from `<link rel="preload" />` stylesheets
import "fg-loadcss/src/cssrelpreload";

// find out more about `font-display` here:
// https://css-tricks.com/font-display-masses/#article-header-id-3
import supportsFontDisplay from "~/utilities/supports/font-display";

const htmlClassNames = ["js"];

if (supportsFontDisplay) {
  htmlClassNames.push("supports-font-display");
}

// overwrites any existing classes on the `<html>` element (e.g. `"no-js"`)
document.documentElement.className = htmlClassNames.join(" ");

This pattern is especially useful when used in conjunction with custom web fonts in order to control FOUT, FOIT, and FOFT.

Inlining the Script

The final step, and the one that I can write the least about, is inlining the compiled critical.min.js into your HTML. The mechanism for this will vary drastically depending on your technology stack and deployment processes.

Field Notes

Are you currently using this approach in your sites and applications? If so, how has your experience been so far? Do you plan to implement Critical JavaScript in the future? What kinds of tasks do you think this is suited to?

Better Focus Indicators Using the `:focus-visible` Pseudo-Class

Saul Hardman — Thu, 13 Feb 2020 06:51:52 +0000

It used to be common practice in web design to "nuke from orbit" the default (and admittedly somewhat jarring) browser styles of the :focus pseudo-class selector.

Even popular CSS styling resets included rules such as this:-

/* remember to define focus styles! */
:focus {
  outline: 0;
}

Speaking from experience, it was often the case that when designers were conducting a review they would express distaste when clicking on links and buttons left lingering dotted outlines and glowing gradients.

Don't get me wrong, I'm not trying to pass the buck here. None of us were aware of how important these focus indicators were to assistive technologies, but it's less forgivable in Today's burgeoning culture of inclusivity and accessibility – and rightly so.

Despite changing our ways – ensuring that :focus styles got the same attention as :hover and its siblings – the question of whether a tap or a click should .focus() an element still remained. There was no practical way to differentiate between this focus scenario and that of an assistive tool or keyboard navigation, until now...

:focus-visible is a new CSS pseudo-class selector that's currently in the draft stages.

The :focus-visible pseudo-class applies while an element matches the :focus pseudo-class and the user agent determines via heuristics that the focus should be made evident on the element.

:focus-visible {
  outline: 2px solid gold;
  outline-offset: 2px;
}

:focus:not(:focus-visible) {
  outline: none;
}

As :focus-visible is only in the draft stages, and support is currently particularly poor, it's necessary to polyfill the behaviour using JavaScript.

Ideally, we'd author styles as if the feature was supported and have a JavaScript module and PostCSS plugin polyfill the behaviour and transpile the syntax respectively.

> npm install --save focus-visible

// an entry point in your application
import "focus-visible";

> npm install --save-dev postcss-focus-visible

// postcss.config.js
module.exports = {
  plugins: [require("postcss-focus-visible")]
};

Note: I'd recommend configuring this plugin in the context of PostCSS Preset Env to tie this transformation to a Browserslist support configuration.

There is one thing to keep in mind when using the :focus-visible pseudo-class selector; the CSS specification dictates that browsers nullify entire rules that contain unknown or invalid selectors. Accordingly, we must create separate rules for all :focus-visible styles (at least until browser support improves):-

/* invalid */
button:hover,
button:focus-visible {
  color: white;
  background-color: blue;
}

/* valid */
button:hover {
  color: white;
  background-color: blue;
}

button:focus-visible {
  color: white;
  background-color: blue;
}

Another issue to be aware of is how these styles are handled by CSS compression tools. cssnano, in particular, is not yet aware that merging rules with invalid selectors is not a safe transformation to make (see this GitHub issue for updates). Until this issue is resolved it's possible to disable the mergeRules option:-

// postcss.config.js
modules.exports = {
  plugins: [
    require("cssnano")({
      preset: [
        "default",
        {
          mergeRules: false
        }
      ]
    })
  ]
};

Additionally, if PurgeCSS is part of your build pipeline, it's necessary to whitelist selectors that include the class name that's dynamically added by the polyfill:-

// purgecss.config.js
module.exports = {
  whitelistPatterns: [/\.focus-visible/],
  whitelistPatternsChildren: [/\.focus-visible/]
};

Authenticate with IndieAuth.com using PGP and Keybase

Saul Hardman — Thu, 09 Jan 2020 12:01:01 +0000

IndieAuth.com is a public instance of IndieAuth, the decentralised identity protocol built on top of OAuth 2.0. In this article I'm going to explain how to authenticate yourself using your domain and a set of PGP keys handled by Keybase. Once you've successfully logged into IndieAuth.com you'll be able to use the same method to authenticate with any IndieAuth service.

There are many methods of authenticating with IndieAuth, but PGP feels the most "Indie". I manage my keys using Keybase which conveniently hosts your public PGP keys in ASCII format. I'd initially presumed that IndieAuth would require keys to be hosted on the domain being used to login, but thankfully that's not the case and so keys hosted remotely on services such as Keybase can be used directly too.

Generating a PGP Key Using Keybase

Once you have Keybase Desktop installed, open up a terminal of your choice and run the following command and follow the steps to generate a PGP key:-

> keybase pgp gen

If you've chosen to generate a new key, alongside an existing key, then you'll need to include the --multi flag.

Once that process is complete, you should now be able to access a hosted copy of your public PGP key at the following URL:-

# NOTE: replace `${YOUR_USERNAME}` with *your* Keybase username
https://keybase.io/${YOUR_USERNAME}/pgp_keys.asc

If you have multiple PGP keys associated with your Keybase account, you can select an individual key by setting the fingerprint parameter:-

# NOTE: run `keybase pgp list` to reveal additional information about existing keys
https://keybase.io/${YOUR_USERNAME}/pgp_keys.asc?fingerprint=${YOUR_KEY_FINGERPRINT}

Link to the Keys

Add the following <link> tag to the <head> of your HTML document:-

<!-- NOTE: replace `${YOUR_USERNAME}` with *your* Keybase username -->
<link
  rel="pgpkey"
  type="application/pgp-keys"
  href="https://keybase.io/${YOUR_USERNAME}/pgp_keys.asc"
/>

To verify that your configuration is working, and on each subsequent IndieAuth login, you will be provided with a snippet of text that you're required to sign using your PGP key. Navigate to the IndieAuth.com site and enter and submit your domain name to the <input> in the "Try it!" section:-

To do that with Keybase, open the command line and (after ensuring that you have Keybase Desktop installed) run the following command, replacing the placeholder text within the single quotes with the challenge text:-

> keybase pgp sign -m 'INSERT CHALLENGE TEXT HERE'

If you're on macOS, you can pipe the output to pbcopy so that you're ready to paste the signed text back into the <input>/<textarea> and submit right away, like so:-

> keybase pgp sign -m 'INSERT CHALLENGE TEXT HERE' | pbcopy

So there you have it, you should now able to authenticate with IndieAuth services using your very own domain and a set of PGP keys.

Lazy Loading Images in Nuxt

Saul Hardman — Wed, 08 Jan 2020 06:42:03 +0000

The lazy loading of images via the loading attribute has landed in Chrome, and other browser-vendors are sure to follow suit. Deferring to the browser when support is available and otherwise loading a polyfill such as Lazysizes is a solid approach to performant, responsive images.

Checking the HTMLImageElement for the loading property is a reliable way to test for native lazy loading support:-

const supportsLoadingAttribute = "loading" in HTMLImageElement.prototype;

If the browser supports native image loading we do nothing, or else we dynamically import() the Lazysizes module. Authoring this code within a client-side only Nuxt plugin means the polyfill loads and initialises only once and within the context of the entire application:-

// ~/plugins/lazysizes.client.js

export default () => {
  if ("loading" in HTMLImageElement.prototype) {
    return;
  }

  import("lazysizes");
};

Below is a loosely outlined ResponsiveImage component which follows the pattern that I want to demonstrate.

The server-side rendered HTML contains an image with the src and srcset values assigned to data-* attributes – the actual attributes contain placeholders. On mount() (a client-side only Vue lifecycle hook) if the browser supports the loading attribute the placeholders are replaced by the true src and srcset values. If support is absent then the class 'lazyload' is added to the <img> and Lazysizes takes over from there:-

<!-- ~/components/ResponsiveImage.vue -->
<template>
  <img
    :class="{ lazyload: loading === 'lazy' && !supportsLoadingAttribute }"
    :loading="loading"
    v-bind="{ ...sources }"
  />
</template>

<script>
  // base64-encoded transparent GIF
  const placeholder =
    "data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==";

  export default {
    props: {
      // the props required to compute `srcset` should go here

      loading: {
        type: String,

        default: "lazy"
      }
    },

    data() {
      return {
        supportsLoadingAttribute: false
      };
    },

    computed: {
      src() {
        // `return` a fallback image for browsers
        // that don't support `srcset` and `sizes`
      },

      srcset() {
        // responsive images can be handled in all sorts of
        // ways and I won't go into any further detail here
      },

      sources() {
        if (this.loading === "lazy" && !this.supportsLoadingAttribute) {
          return {
            "data-src": this.src,
            "data-srcset": this.srcset,

            src: placeholder,
            srcset: `${placeholder} 1w`
          };
        }

        return {
          srcset: this.srcset
        };
      }
    },

    mounted() {
      this.supportsLoadingAttribute = "loading" in HTMLImageElement.prototype;
    }
  };
</script>

There's are many different approaches to lazy-loading images on the web. Each has its advantages and disadvantages and the one you choose will ultimately depend on your priorities. Are you more concerned about SEO, page speed, data footprint, or browser compatibility?

The pattern outlined above, for example, would need to provide a <noscript> fallback in the case of JavaScript being disabled.

Either way, hopefully this has started you off in the right direction. Check out the links below for some more in-depth explanations of the loading attribute and lazy-loading markup patterns.

Verifying a Nuxt Site on Flattr

Saul Hardman — Mon, 06 Jan 2020 15:51:29 +0000

Out of the box, Nuxt sites cannot be used to verify domains on Flattr.

The only way to verify a domain with the service is to include a <meta> tag in the <head> of all the pages on your site. The Flattr verification service expects this tag to have 2 attributes and 2 attributes only:-

<meta name="flattr:id" content="abc123" />

The reason that this doesn't play nice with Nuxt is due to data-n-head attributes being added to all <meta> and <link> tags. The solution is to hook into specific Nuxt events and modify the HTML appropriately:-

// nuxt.config.js
import cheerio from "cheerio";

const removeDataAttributeFromFlattrMetaTag = html => {
  const $ = cheerio.load(html);

  $('meta[name="flattr:id"]').removeAttr("data-n-head");

  return $.html();
};

export default {
  head: {
    meta: [{ name: "flattr:id", content: "abc123" }]
  },

  hooks: {
    generate: {
      page(page) {
        page.html = removeDataAttributeFromFlattrMetaTag(page.html);
      }
    },

    render: {
      route(url, page) {
        page.html = removeDataAttributeFromFlattrMetaTag(page.html);
      }
    }
  }
};

Stripping the data-n-head attributes from the <meta> tags in this way is enough to appease the Flattr verification service. I have spoken with the support team at Flattr and brought this issue to their attention, but this workaround will suffice for now.

This attribute serves some purpose in the handover between Nuxt SSR and client-side hydration and originates from the Vue Meta plugin. I presume that removing the attribute in the manner outlined above doesn't cause any issues – especially since this attribute won't be updated elsewhere. But, if you're looking for an alternative, you can add the <meta> tag to the app template instead:-

<!-- ~/app.html -->
<!DOCTYPE html>
<html {{ HTML_ATTRS }}>
  <head {{ HEAD_ATTRS }}>
    <meta name="flattr:id" content="abc123" />
    {{ HEAD }}
  </head>
  <body {{ BODY_ATTRS }}>
    {{ APP }}
  </body>
</html>

UPDATE: After getting to know Vue Meta a little better, I discovered the once special metaInfo attribute. This disables reactivity and, in the case of Nuxt, only outputs the tag during server-side rendering (without data-* attributes):-

// nuxt.config.js
export default {
  head: {
    meta: [{ name: "flattr:id", content: "abc123", once: true }]
  }
};

Configuring PurgeCSS for Use With Nuxt

Saul Hardman — Mon, 06 Jan 2020 11:32:56 +0000

PurgeCSS is a tool for removing unused CSS. It achieves this by cross-checking the compiled CSS with a list of selectors that are extracted from the content files (e.g. HTML files, JavaScript modules, and Vue components).

Using PurgeCSS out of the box with Nuxt resulted in styles included via @import statements being correctly purged – both from 1st- and 3rd-party sources. However, due to the configuration of the default extractors, styles authored within Vue component <style> blocks were incorrectly preserved.

Configuring the PurgeCSS PostCSS plugin as follows remedies the problem:-

// nuxt.config.js
export default {
  build: {
    postcss: {
      plugins: {
        "@fullhuman/postcss-purgecss": {
          extractors: [
            {
              extractor: content =>
                content
                  .replace(/<style[\s\S]*>[\s\S]*<\/style>/gi, "")
                  .match(/[\w-/:]+/g) || [],

              extensions: ["vue"]
            }
          ]
        }
      }
    }
  }
};

Ideally this extraction behaviour would be consolidated within a tested and maintained package such as purge-from-vue. That way it could be used in all Vue-based projects.

UPDATE (2020-03-21): Reflect change to extractor format in PurgeCSS v2.0 release.

How to Configure Yarn on Netlify

Saul Hardman — Mon, 22 Jul 2019 00:00:00 +0000

Netlify Build is a great platform for running static site builds in conjunction with your Git workflow and Headless CMS content updates (via Webhooks). It makes running cloud-based builds of JavaScript Static Site Generators very slick, but it's not without its pitfalls.

Many of the popular generators use Yarn as a package manager which can be configured via Netlify's netlify.toml configuration file, like so:-

# netlify.toml

[build.environment]
  YARN_VERSION = "1.17.3"
  NODE_ENV = "production"

Note: the "Yarn approved" method of specifying the required version is via the yarn policies set-version command.

Running the build step in an environment other than local development had me wondering whether to install packages as dependencies or devDependencies. With the environment variable NODE_ENV set to "production" Yarn will only install dependencies specified in the dependencies section of the package.json file, and not those within devDependencies.

Perhaps NODE_ENV could be set to "production" within the scope of the build command? For example:-

{
  "scripts": {
    "build": "NODE_ENV=production ..."
  }
}

The cleanest solution (in my humble opinion) is to set the --production flag to false, like so:-

# netlify.toml

[build.environment]
  YARN_VERSION = "1.17.3"
  YARN_FLAGS = "--production=false"
  NODE_ENV = "production"

You can find out more about configuring build environment variables within the Netlify documentation.

How the Netlify Build Queue Works

Saul Hardman — Mon, 20 Nov 2017 00:00:00 +0000

I’m using Netlify in conjunction with Contentful and have configured a Contentful Outgoing Webhook to trigger a Netlify Build Hook when content is updated. This got me wondering whether or not Netlify operates a build queue and, if so, how it works.

There is (at the time of writing) no formal documentation on this topic, so I hopped onto the Netlify Gitter conversation to see what I could find out. Thankfully Mathias Biilmann (the founder of Netlify, no less) was on hand to enlighten me.

It turns out they does use a build queue and this is how it operates:

We’ll start the first one, and then once that’s done, our system will mark all the intermediary builds as “Skipped” and then run the last one

Thankfully this is the logic that I was hoping for 🎉

In the case of the Contentful Content Preview API, the webhooks can be triggered fairly frequently (up to 3 times a minute) whilst content is being edited. My worry was that this was creating a race condition that could result in stale content winning out over fresh content. Thankfully these worries were unfounded.

Using `vuex-router-sync` with Vuex Modules and Nuxt

Saul Hardman — Tue, 14 Nov 2017 00:00:00 +0000

The scenario is relatively straight-forward: we have a Vuex module located in ~/store/projects.js and we'd like to define a getter called currentProject which .find()s a project based on the current route params.

We'll start by installing the vuex-router-sync module:

> yarn add vuex-router-sync

We then define a Nuxt.js Plugin to sync() the store and the router:

// ~/plugins/vuex-router-sync.js
import { sync } from "vuex-router-sync";

export default ({ app: { store, router } }) => {
  sync(store, router);
};

(Sourced from this GitHub issue.)

For this to be run during initialisation we need to declare it in our Nuxt.js config:

// nuxt.config.js
module.exports = {
  plugins: ["~/plugins/vuex-router-sync"]
};

The module 'route' is now available in the store and is kept in sync with the vue-router instance.

Returning to our 'projects' Vuex module, we are now able to define a getter that .find()s a project based on the current route parameter id:

// ~/store/projects.js
export const state = () => ({ projects: [] });

export const getters = {
  currentProject: (state, getters, rootState) =>
    state.projects.find(project => project.id === rootState.route.params.id)
};

DEV Community: Saul Hardman

A Word of Caution Regarding Cross-Posting To DEV

Managing Access Tokens with GitHub Actions and Encrypted Secrets

Create an Encrypted Secret

Pass a Secret as an Environment Variable

Create a Scheduled Workflow

A Note on Netlify

Local Testing

Closing Thoughts

Publishing and Installing Private GitHub Packages using Yarn and Lerna

Setup the Mono-Repository

Create the Packages

Authenticate with the GitHub Package Registry

Publish the Packages

Installing Private GitHub Packages

Installing Private GitHub Packages from GitHub Actions

Closing Thoughts

Additional Resources

Generate a Critical JavaScript Bundle Using Rollup

Keep Things Simple

Why Rollup

Inlining the Script

Field Notes

Better Focus Indicators Using the `:focus-visible` Pseudo-Class

Authenticate with IndieAuth.com using PGP and Keybase

Generating a PGP Key Using Keybase

Link to the Keys

Lazy Loading Images in Nuxt

Further Reading

Verifying a Nuxt Site on Flattr

Configuring PurgeCSS for Use With Nuxt

How to Configure Yarn on Netlify

How the Netlify Build Queue Works

Using `vuex-router-sync` with Vuex Modules and Nuxt