DEV Community: Andy Coupe

Retrieve every key from a union of objects

Andy Coupe — Tue, 20 Feb 2024 21:40:22 +0000

Find it on my new blog...

My new blog post

Don't Fear Custom Radio Buttons

Andy Coupe — Mon, 01 Aug 2022 10:36:25 +0000

Creating Custom Radio Groups

A few HTML form elements strike fear into some developers when the request for a custom-styled variant arises.

The select element 😱
The checkbox 🙀
The radio button/input 😧

Today we grab the radio input and give it some finesse ✨ Our solution will be fully accessible and make use of our native radio input's focus and checked states to apply some styles to give us something like the below.

What is a Radio Group?

It is a set of checkable buttons, known as radio buttons, where no more than one of the buttons can be checked at a time.

Believe it or not but they are called radio buttons because they look and operate in a similar manner to the push buttons on old-fashioned radios, whereby only one button could be selected at a time.

Accessibility

Our solution will conform to the WCAG guidelines below thanks to us using the native radio input element as opposed to using alternative elements and having to apply aria attributes everywhere.

Tab and Shift + Tab should move focus into and out of the radio group. When the focus moves to a radio group:
- If a radio button is checked, the focus is set on the checked button.
- If none of the radio buttons are checked, the focus should be set on the first radio button in the group.
Space should check the focused radio button if it is not already checked.
Right Arrow and Down Arrow should move focus to the next radio button in the group, uncheck the previously focused button, and check the newly focused button. If the focus is on the last button, the focus moves to the first button.
Left Arrow and Up Arrow should move focus to the previous radio button in the group, uncheck the previously focused button, and check the newly focused button. If the focus is on the first button, the focus moves to the last button.

Creating our HTML

Let's start off by creating a radio group component which will be the parent of our radio button children and add the role of radiogroup to signal this information to assistive technologies.

Next up is our Radio component. The idea here is to use the label element to style our custom radio button. The advantage is that our label is associated with an input element via the htmlFor React attribute, so interactions with our label will propagate to our radio input allowing us to style the label based on the input element's state.



import React, { PropsWithChildren } from "react";

export const RadioGroup = ({ children }: PropsWithChildren<{}>) => {
  return (
    <div
      role="radiogroup"
      className="radio-group"
      aria-labelledby="group_heading"
    >
      <h2 id="group_heading">Select a button</h2>
      {children}
    </div>
  );
};

export const Radio = ({
  children,
  id,
  name
}: PropsWithChildren<{ id: string; name: string }>) => {
  return (
    <>
      <input type="radio" id={id} name={name} />
      <label className="radio-label" htmlFor={id}>
        {children}
      </label>
    </>
  );
};

Styles



* {
  font-family: "Inter";
  --grey: #ededed;
  --blue: #0037fc;
}

h2 {
  margin: 0;
  font-weight: bold;
}

p {
  margin-bottom: 0;
}

.radio-group {
  display: flex;
  gap: 16px;
  margin-top: 32px;
}

/* Hide the native radio input */
input[type="radio"] {
  appearance: none;
  opacity: 0;
  position: absolute;
}

label {
  position: relative;
  padding: 48px 16px;
  border-radius: 8px;
  box-shadow: 2px 2px 6px 0px var(--grey);
}

label::after {
  content: "";
  position: absolute;
  width: 20px;
  height: 20px;
  border-radius: 50%;
  right: 16px;
  top: 16px;
  background: var(--grey);
}

/* When the radio is checked, style the label accordingly */
input[type="radio"]:checked + label {
  background: #ebefff;
  outline: solid 3px var(--blue);
}

/* When the radio is focused, style the label accordingly */
input[type="radio"]:focus + label {
  outline-offset: 3px;
}

/* When the radio is checked, style the pseudo-element accordingly */
input[type="radio"]:checked + label::after {
  background: var(--blue);
}

A Code Sandbox is available below.

https://codesandbox.io/s/nameless-tree-d8yhww

Summary

Our solution conforms to the WCAG guidelines when using the keyboard and we have accessible styling applied when our radio buttons are in their focus and checked states.

We've achieved this by setting our input and label elements alongside each other, just like the happy siblings they are.

Adios.

No need for web fonts - give the browser a break!

Andy Coupe — Thu, 27 Jan 2022 09:15:51 +0000

Are you using a snippet provided by Google Fonts to load fonts for your web application?

What if I told you that the cool kid on the block (Vercel) has some performance gains for you?

Quicker page load
Reduced network requests
Version locked fonts
Offline support

You can take advantage of these gains by using a library they've provided called Fontsource.

It's a monorepo full of open source fonts which are version locked (unlike google Fonts, who can update a font at any given time), allowing you to manage your fonts like any other project dependency.

By using Fontsource you're also giving the browser a break and skipping a render-blocking request as your fonts will be hosted right there in your production code. No need to go and get the css file and then download the fonts. Check out some of the performance benchmarks here 🔥

Google also performs some tracking on their fonts, so sticking with a Google web font ties you into being tracked without warning.

Fontsource doesn't just support Google Fonts either, they have an evolving set of open source fonts too!

Using Fontsource also allows your fonts to work offline which is great for PWAs and also working locally, as your fonts are available without the need for fetching.

Here's an example of how to get started in a NextJS project using the Google Font, Inter.

yarn add @fontsource/inter

Then all we need to do is import it wherever we want to use it. In this example I want it available globally in my app, so I'm importing it in my _app.tsx.

import "@fontsource/inter";

Fontsource also allows you to select weights and even styles, allowing you to trim the payload!

import "@fontsource/inter/700.css";
import "@fontsource/inter/700-italic.css"

The font can then be referenced anywhere in your application using a CSS stylesheet, CSS Module, or CSS-in-JS.

body {
  font-family: "Inter", sans-serif;
}

Give Fontsource a go, it makes life so much easier when dealing with fonts!

Use GraphQL without writing GraphQL

Andy Coupe — Sun, 19 Dec 2021 12:49:45 +0000

👍 Follow me on Twitter @andycoupedev

In this walkthrough, we are going to create a full stack application with full type safety using GraphQL without writing any actual GraphQL with the star of the show being GenQL. Below is a list of tools we will be using.

TypeScript - typed JavaScript from the future.
Hasura - instant GraphQL and REST APIs on new or existing data sources.
React Query - manage fetching, caching and server state easily.
GenQL - Generate a type safe GraphQL client for our GraphQL API.
NextJS - Arguably the best React framework.

Create our frontend

To generate our frontend let's create our NextJS TypeScript project with the following command from a directory of your choice.

npx create-next-app@latest your-app-name --ts

Create our GraphQL API

For our GraphQL API, let's head over to Hasura and create a project - you'll need to create an account. Once you've done that, select the create project option and select all of the free tier options. Click "Launch Console" and you should be presented with the Hasura console.

We have rapidly generated the frontend and API layers of our application, leaving just the DB layer left. Thankfully, Hasura has our back.

Click on the "Data" tab from the Hasura console and you should see a button to connect a database. From here, there should be a "Create Heroku database" option. Follow these steps (you may have to sign up to Heroku if you're not already signed up) and we'll have a Postgres database managed by Heroku, connected to our GraphQL API.

Create our database

Now, let's create a table. For this application I'm going with a football (soccer) theme so let's name our table teams.

The frequently used columns button is useful and lets us quickly add columns id, created_at and updated_at. Add a column of type Text named name to store our team names as well.

Click "Add table" to create the table.

After creating the table, the insert row tab will allow us to manually create a row in the table, let's do that and hit "Save".

Head over to the "API" tab and you will now be able to query the data from our database using Hasura's playground 😎.

Back to the frontend

We have our backend setup. To interact with our GraphQL API from our frontend we are going to generate a GraphQL client using GenQL so we need to install some dependencies in our NextJS application.

npm i -D @genql/cli # cli to generate the client code
npm i @genql/runtime graphql # runtime dependencies

@genql/cli is a dev dependency because it is only required to generate the client, @genql/runtime instead is a direct dependency of the generated code.

To generate our client we can use the following command.

 genql --endpoint <your graphql endpoint from hasura console> --output ./genql-generated -H 'x-hasura-admin-secret: <your admin secret from hasura console>'

The generated files expose a function createclient. This creates a client you can use to send requests.

Let's create a file at the root of our project named genql-client.ts with the following contents to create our client.

import { createClient } from "./genql-generated";

const client = createClient({
    url: <your graphql endpoint from the hasura console>,
    headers: {
        'x-hasura-admin-secret': <your hasura admin secret from hasura console>,
    },
})

With our GraphQL client in our holster, we're ready to start firing requests.

We are going to use React Query to manage fetching and server state.

npm i react-query

For the purpose of this walkthrough we will just make the request in the default index page provided by NextJS. So head to pages/index.tsx and import our client below the rest of the existing imports.

I like to work inside the src directory so your imports may be a level higher than mine. NextJS supports moving the pages directory into a src directory out of the box.

// ...existing imports
import { client } from '../../genql-client'

Let's create a function to fetch the teams in our database. Don't just copy and past the code below. Type it out and appreciate the autocompletion using CMD or CTRL + SPACE depending on your OS 😎

const fetchTeams = () => {
  return client.query({
    teams: [{}, { id: true, name: true, created_at: true }],
  });
};

Consult the GenQL docs on the syntax but you can get the general idea of how to build a query. Once again, autocompletion will guide you like a good friend.

Our generated files also export an object called everything which allows us to query all fields in a type instead of providing a boolean to every type, like so.

// ...existing imports
import { everything } from "../../genql-generated";

const fetchTeams = () => {
  return client.query({ teams: [{}, everything] });
};

Now let's bring in useQuery from React Query and wire it up to our fetchTeams function.

// ...existing imports
import { client } from "../../genql-client";
import { everything } from "../../genql-generated";
import { useQuery } from "react-query";

Invoke the useQuery hook inside the Home page component and provide it with your query key and query function as the second and third arguments respectively.

  const { data } = useQuery("teams", fetchTeams);

Almost there! We need to wrap our app in a <QueryClientProvider /> component provided to us by React Query. This will have to be added further up the tree in the _app.tsx file. Update _app.tsx with the following code.

import type { AppProps } from "next/app";
import { QueryClientProvider, QueryClient } from "react-query";

const queryClient = new QueryClient();

function MyApp({ Component, pageProps }: AppProps) {
  return (
    <QueryClientProvider client={queryClient}>
      <Component {...pageProps} />
    </QueryClientProvider>
  );
}

export default MyApp;

Let's update our index.tsx page to look like the following and we should be seeing our team rendering on the page.

import type { NextPage } from "next";
import styles from "../styles/Home.module.css";

import { useQuery } from "react-query";
import { client } from "../../genql-client";
import { everything } from "../../genql-generated";

const fetchTeams = () => {
  return client.query({ teams: [{}, everything] });
};

const Home: NextPage = () => {
  const { data, isLoading } = useQuery("teams", fetchTeams);

  return (
    <div className={styles.container}>
      <h1>Teams</h1>
      {isLoading && <p>Loading...</p>}
      {data && data.teams.map((team) => <p key={team.id}>{team.name}</p>)}
    </div>
  );
};

export default Home;

There are certain best practices to follow when using React Query with SSR/NextJS that are beyond the scope of this walkthrough which can be found here.

I may do a follow up post using mutations and GenQL to create a CRUD application but hopefully this has shown you the power of GenQL

Sit down at my Jest Tagged Template Literal table and tidy up your tests.

Andy Coupe — Tue, 09 Feb 2021 23:25:32 +0000

Scenario

We have a really simple button component which receives a status on the props object and renders different button text based on the value of the status.

This simple component will be called LouisButton. The value of the status prop will be one of four values which can be seen in the code below.

const buttonTextMapper = {
  available: 'Buy now',
  unavailable: 'Unavailable',
  reserved: 'This product is reserved',
  outOfStock: 'Out of stock',
}

type ButtonProps = {
  status: 'available' | 'unavailable' | 'reserved' | 'outOfStock'
}

export const LouisButton: React.FC<ButtonProps> = ({ status }) => {
  const buttonText = buttonTextMapper[status]

  return (
    <button>{buttonText}</button>
  )
}

Now let's write some tests for LouisButton using Jest and React Testing Library.

import { render } from '@testing-library/react'
import { LouisButton } from './button'

describe('LouisButton', () => {
  it('should render "Buy now" if the status is available', () => {
    const {getByText} = render(<LouisButton status={'available'}/>)

    expect(getByText('Buy now')).toBeInTheDocument()
  })

  it('should render "Unavailable" if the status is unavailable', () => {
    const {getByText} = render(<LouisButton status={'unavailable'}/>)

    expect(getByText('Unavailable')).toBeInTheDocument()
  })

  it('should render "This product is reserved" if the status is reserved', () => {
    const {getByText} = render(<LouisButton status={'reserved'}/>)

    expect(getByText('This product is reserved')).toBeInTheDocument()
  })

  it('should render "Out of stock" if the status is outOfStock', () => {
    const {getByText} = render(<LouisButton status={'outOfStock'}/>)

    expect(getByText('Out of stock')).toBeInTheDocument()
  })
})

Remember, this is a simple button. But if more statuses were to be added, things could get ugly. We can improve this and make things easier to digest for the next developer who comes working in this area.

Say hello to it.each 👋

 it.each`
      status           | buttonText
      ${'available'}   | ${'Buy now'}
      ${'unavailable'} | ${'Unavailable'}
      ${'reserved'}    | ${'This product is reserved'}
      ${'outOfStock'}  | ${'Out of stock'}
  `('should render $buttonText if the status is $status', ({buttonText, status}) => {
    const {getByText} = render(<LouisButton status={status}/>)

    expect(getByText(buttonText)).toBeInTheDocument()
  })

Jest will run a test across each row in the tagged template literal table, mapping the title of each column to a variable which you can see in the test description, preceded by a dollar sign. This helps make your test descriptions read nicely.

We can then destructure these variables and use them in our assertions. I think this pattern is much more maintainable than continuously adding more it blocks.

If another set of statuses are introduced then it's no big deal. Just add them to the table 😀

Thanks for reading 👍

TypeScript's enum + JavaScript's "in" = 👍

Andy Coupe — Sun, 08 Nov 2020 22:37:49 +0000

At cinch, I work on the inventory team and we manage all of the vehicle inventory, tracking the status, location and all kinds of other data for thousands of cars. We have an event driven architecture which means parts of our code respond to certain events which we subscribe to. We have a state machine/model which contains a LOT of logic to determine moving cars from one status to another. I came up with the following pattern when I noticed some hefty if conditions in the codebase.

In this example I'm going to use robots as the subject as I write code to do with vehicles every day! 🚗

Let's imagine we want a function which disposes of a robot but we can only dispose of the robot if it's status is faulty or damaged. Below we setup our enum RobotStatus to list our possible robot status and a Robot interface to build the shape of our robot.

enum RobotStatus {
    ready,
    damaged,
    faulty
}

interface Robot {
    name: string
    status: RobotStatus
}

function disposeRobot(robot: Robot): void {
    if (robot.status === RobotStatus.damaged || 
        robot.status === RobotStatus.faulty
    ) {
        console.log('Disposing of robot...')
    }

    console.log('Robot in incorrect state to dispose...')
}

This is fine for now. But imagine if we had to start adding more checks for other status. Let's add some more for discontinued, dead, old, rusty, and dangerous.

enum RobotStatus {
    ready,
    damaged,
    faulty,
    discontinued,
    dead,
    old,
    rusty,
    dangerous
}

interface Robot {
    name: string
    status: RobotStatus
}

function disposeRobot(robot: Robot): void {
    if (robot.status === RobotStatus.damaged || 
        robot.status === RobotStatus.faulty ||
        robot.status === RobotStatus.discontinued ||
        robot.status === RobotStatus.dead ||
        robot.status === RobotStatus.old ||
        robot.status === RobotStatus.rusty ||
        robot.status === RobotStatus.dangerous ||
    ) {
        console.log('Disposing of robot...')
    }

    console.log('Robot in incorrect state to dispose...')
}

Now that if block is getting chunky and it stinks 👃.
Let's create an enum containing our allowed disposable statuses.

enum DisposableStatus {
    damaged,
    faulty,
    discontinued,
    dead,
    old,
    rusty,
    dangerous
}

JavaScript has an in operator which will return true if the specified property exists in the specified object.

prop in object

This can clean up our if block from above. Let's use it...

function disposeRobot(robot: Robot): void {
    if (robot.status in DisposableStatus) {
        console.log('Disposing of robot...')
    }

    console.log('Robot in incorrect state to dispose...')
}

TypeScript will compile the enum into a regular JavaScript object and these properties will exist at runtime 👍.
This is much more readable and easier to digest for your future self and other developers.

My Heisenberg, Breaking Bad VS Code theme

Andy Coupe — Mon, 20 Jul 2020 06:17:53 +0000

I don't know about you but I find myself switching between color themes in Visual Studio Code on an almost weekly basis. I thought I would create my own and used the colors from the hit TV show, Breaking Bad. The colors used are explained below with credit to Luke Villapaz's article on why the director chose to use certain colors during filming.

GitHub Repository: Heisenberg Theme

🚨Red - When characters in the series are wearing the color, it tends to connote aggression, violence, danger and murder.

🟠 Orange - the color used for warning and danger during the show. Often in the “Breaking Bad” series, orange clothing will be worn by characters or orange objects will be present in a scene right before something dangerous or deadly happens.

🟡 Yellow - In the “Breaking Bad” series, yellow is most often associated directly with the meth cooking, selling and laundering operation. Yellow also signifies caution, which is taken more and more as Walt becomes more experienced in the meth business.

🧪💵 Green - Green serves as the personification of desperation, envy, and greed. Starting from the pilot of "Breaking Bad," Walt is seen wearing a green apron as he makes his first batch of meth. While he initially turned to meth cooking out of desperation to secure his family's future, it evolved into greed as he experienced the power and vast wealth his meth provided him.

💎 Blue - Blue serves multiple symbolic purposes. When objects are colored blue, they tend to signify purity, escape and security. The iconic blue meth Walt and Jesse cook was of the highest purity.

🟣 Purple - Gilligan offered this explanation of the color purple in his interview with Vulture, “Well, Marie would say purple is the color of royalty.”

💖Pink - Well, Jesse Pinkman 😉

⚪️ White - Walter White 😎 White is often used in direct contrast with black. The White family lived on Negro Arroyo Lane. In Spanish this translates to, “black stream”. In the case of Walt, a dark path he is leading his family down.

⚫️ Black - Black represents several things throughout the series. Death, deception, nefariousness, evil, and power are all represented through it. One of the of signature uses of black in the “Breaking Bad” series is seen through the black hat Walt puts on at different times of the series. Every time he puts on the hat, he is affirming his power and scheming for a dark purpose.

Credits: Breaking Bad color theory by Luke Villapaz

How I simplified my import paths in TypeScript

Andy Coupe — Fri, 17 Jul 2020 08:10:31 +0000

I think as developers using ES modules we have all got to a point where import paths start to become ugly and unmaintainable - especially in large codebases.

With a couple of lines added to your tsconfig.json we can fix this.

Let's imagine we are importing a button into a file which is nested far away from the components directory.

import Button from '../../../components/button'

This doesn't look too bad but it can get quite annoying if you're having to do this regularly.

Jump over to your tsconfig.json and reach into your tool belt.

We can add a paths property to our tsconfig.json. By doing this we also need to add a baseUrl which our paths will use as a base.

{
    "compilerOptions": {
        "baseUrl": "src",
        "paths": {
          "@components/*": ["components/*"]
        }
    }

}

Now we can use these paths in our application. @components will now map to src/components/*.

So our button import from before can now be used like so.

import Button from '@components/button'

It doesn't look like much but in a monorepo this improves your workflow and efficiency as a developer.

A short but hopefully helpful post for some importers out there.

Cheese on Toast with React Portals?

Andy Coupe — Mon, 20 Apr 2020 09:39:34 +0000

Portals allow elements to sit within the React component tree but render to an alternative container in the DOM.

This can be useful when we want to render elements such as modals, tooltips, toast notifications from anywhere within our React application.

Also, events inside a portal will propagate to ancestors in the containing React tree, even if those elements are not ancestors in the DOM tree.

Even though a portal can be anywhere in the DOM tree, it behaves like a normal React child in every other way. Features like context work exactly the same regardless of whether the child is a portal, as the portal still exists in the React tree regardless of position in the DOM tree.

I used a simple code sandbox to create this mini tutorial/explanation which can be found at the end of this post.

Create our `portal-root`

The portal root is going to be an empty div which sits alongside our React root element.

Open your index.html file and create your portal-root

  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
    <div id="portal-root"></div>
    <!--
      This HTML file is a template.
      If you open it directly in the browser, you will see an empty page.

      You can add webfonts, meta tags, or analytics to this file.
      The build step will place the bundled scripts into the <body> tag.

      To begin the development, run `npm start` or `yarn start`.
      To create a production bundle, use `npm run build` or `yarn build`.
    -->
  </body>

Cool. Save the file and be done with it.

Create our `ToastPortal` component.

const ToastPortal = ({ children }) => {
  // Find our portal container in the DOM
  const portalRoot = document.getElementById("portal-root");

  /* 
     Create a div as a wrapper for our toast
     using the useMemo hook so that a new value isn't 
     computed on every render
  */
  const toastContainer = React.useMemo(() => document.createElement("div"), []);

  React.useEffect(() => {
  /* 
     Append our toast container to the portal root
  */
    portalRoot.appendChild(toastContainer);

  /* 
     Clean up the DOM by removing our toast container
     when the component is unmounted
  */
    return () => {
      toastContainer.remove();
    };
  });

  /* 
     Render any child elements to the portal root
  */
  return createPortal(children, portalRoot);
};

Render the cheese on toast

Now let's put our portal to use by rendering a classic in most Michelin Star restaurants, cheese on toast. Replace the code inside your App component with the following.

export default function App() {
  const [isToastVisible, setIsToastVisible] = React.useState(false);
  const [inputValue, setInputValue] = React.useState("Hi");

  const handleClick = () => setIsToastVisible(!isToastVisible);
  const handleChange = ({ target }) => setInputValue(target.value);

  return (
    <div className="App">
      <input value={inputValue} onChange={handleChange} />
      <button onClick={handleClick}>{isToastVisible ? "Close" : "Open"}</button>

      {isToastVisible && (
        <ToastPortal>
          <div
            style={{
              position: "fixed",
              top: 8,
              right: 8,
              backgroundColor: "pink",
              borderRadius: 8,
              padding: 8
            }}
          >
            <span role="img" aria-label="cheese on toast">
              🧀
            </span>
            on toast
            {inputValue}
          </div>
        </ToastPortal>
      )}
    </div>
  );
}

The toast notification is rendered outside of our React application but still has the ability to interact with our application state. 😎

This is a decent use case for implementing a custom usePortal hook. Try it out!

Conclusion

Hopefully this has given you an insight into how portals work and the flexibility they can provide. Next time you want to render a modal, tooltip, sidebar nav etc - maybe you could reach out to React Portals.

Build and deploy your GatsbyJS app to Azure using GitHub Actions

Andy Coupe — Thu, 09 Apr 2020 06:57:40 +0000

Prerequisites

Sign up for a free trial Azure account (https://azure.microsoft.com/)
A GitHub account

By the end of this tutorial you should have a Gatsby web app, hosted on Azure Blob Storage, deployed using GitHub Actions whenever we push code to our master branch.

If sign up for Azure is complete and you've verified everything, then let's head over to the Azure Portal and create a resource.

Create a resource
Find and select Storage Account
Select free trial subscription
Create a new resource group name
Create a storage account name

You're safe to click on Review + create now which should pass validation checks and allow you to click Create, initialising the storage account deployment.

Click Go to resource.

Scroll down the left sidebar to find Static Website under Settings. Click that and select Enabled followed by adding index.html as the index and error document paths - hit Save.

You should now see your primary endpoint which is were our GatsbyJS app will live.

Create our GatsbyJS app

We will follow Gatsby's quick start to get our app up and running quickly.

Install the Gatsby CLI

npm install -g gatsby-cli

Create a new site

gatsby new azure-gatsby-site

Change directories into site folder

cd azure-gatsby-site

Start development server

gatsby develop

Gatsby will start a hot-reloading development environment accessible by default at http://localhost:8000

Open the app with your code editor or IDE and navigate to src/pages/index.js. Let's change the <h1> which will reload our app in the browser.

<h1>My Gatsby site on Azure</h1>

Head over to GitHub and create a new repository for your Gatsby code and then git initialise and push our Gatsby site to the repository.

git init
git add .
git commit -m "first commit"
git remote add origin <ORIGIN_URL_HERE>
git push -u origin master

Now we have our Azure Storage Account setup and our Gatsby site pushed to our GitHub repository 😀 We're in a good place!

Now go back to your Azure portal and open your Storage Account and click on Access keys in the side bar, then copy the Connection string

Go to your GitHub repository and click settings>secrets then add your secret as BLOB_STORAGE_CONNECTION_STRING, pasting in your connection string as the value. This will make it available for us to use as an environment variable in our GitHub Actions workflow.

Click the Actions tab followed by setup a workflow yourself.

This will add a .github/workflows/main.yml file to your repository and open a live code editor within GitHub. Remove everything in the code editor and replace with this.

name: Build and deploy Gatsby site to Azure Blob Storage

on:
  push:
    branches:
      - master #on push to the master branch do the jobs below

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@master

      - name: Set up Node.js version
        uses: actions/setup-node@v1
        with:
          node-version: '12.x'

      - name: npm install and build
        run: |
          npm install
          npm run build
      - name: Upload To Azure Blob Storage
        uses: bacongobbler/azure-blob-storage-upload@v1.0.0
        with:
          source_dir: public #gatsby build generates this file after build
          container_name: $web
          connection_string: ${{ secrets.BLOB_STORAGE_CONNECTION_STRING }}

Click on Create commit and then pull these changes locally, ensuring you can see the main.yml file in your code editor. Then go ahead and make a change to the README.md file and push the change to GitHub. Clicking the actions tab in GitHub should now show you your workflow running and successfully deploying to Azure Blob Storage 😀

If you visit the Static website primary endpoint which Azure gave us earlier you should see your GatsbyJS site.

GitHub Actions are cool and this is only touching the surface of what they can do for your development workflow.