Forem: Monica Powell

Tips for Debugging Software like a Detective

Monica Powell — Sat, 15 May 2021 12:51:13 +0000

Being an effective web developer when investigating a software issue, locally or in production, requires some detective-like debugging skills. As I've grown as a developer I've not only improved the breadth of my knowledge about various ways software can break in unexpected ways but I've also enhanced my debugging skills over time.

// Detect dark theme var iframe = document.getElementById('tweet-1392464056011866114-803'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1392464056011866114&theme=dark" }

In this article, I share a longer-form version of the above Twitter thread which highlights some of my thoughts on various ways to approach understanding why the computer doesn't appear to be doing what you tell it to do. Computers interpret instructions literally and to resolve a discrepancy between actual and expected functionality you may need to revisit your assumptions!

Software engineers can hold a lot of ill-informed assumptions or falsehoods which can lead to subpar handling of "edge cases" like assuming a user's name is permanent or that a name must by X characters or that a name is only structured as first name, middle name, last name when in reality that is not a universal fact. Check out awesome-falsehood if you'd like to learn more about common falsehoods that engineers believe about things like time, names, addresses, and more.

If an issue seems to be isolated to my local environment and has gone from working to not working without any notable software changes I may try "turning it on and off again" by trying some of the following: rebuilding database, doing a fresh install of node_modules, restarting docker or your computer, etc. But what do you do when just turning it on and off again doesn’t resolve the issue?

Run linting and read any errors Is there a blaring syntax error? Is your code referencing an undefined variable? More times than I care to admit my code wasn't compiling locally because there was a rouge letter 'f' that I somehow added to a random line. This misplaced char is often picked up by my linting but if I do want to manually skim my changes since the app successfully compiled then I will use the VSCode Git Lens Integration to see if anything stands out as off with my changes. Similar to linting errors, if there are other errors in your terminal, browser console, or webpage that are appearing when your app fails to compile or under the unexpected condition they can help guide your search to figure out what is going wrong. When I first was learning how to program, I more so stared 😳 at error messages instead of reading them. If you're still getting comfortable with error messages check out Nicky Meuleman tips on learning to appreciate errors.
Only change one thing at a time. It can be tempting to change everything at once. But try just changing one thing and before you change it think through how that one change will help you confirm or reject your current assumptions of the problem and ultimately help you further your understanding and bring you closer to a potential solution. Automated tests can be helpful to confirm how changes work under different test cases and to ensure as you progress through the problem you don't unknowingly break preexisting test cases that were previously passing.
Confirm all of your assumptions. Consistently reproduce the issue manually or with tests. Under what conditions does the system fail? To better understand an underlying issue you should determine what conditions it behaves unexpectedly in. Using logs, breakpoints, tests, check network calls, etc to sort out when it fails will get you closer to understanding why it's not working as expected. Is your API actually returning the data you expect? Is it an environment-specific issue? Are there missing environment variables?
Lean on tests to automate confirming your assumptions and testing potential solutions Approaching development with a red-green refactor development approach of defining desired functionality in test, implementing code to make the test go from red to green, and then refactoring without having to worry about unknowingly breaking the desired functionality. This approach prevents building out too much of a feature without testing its functionality and if bugs are resolved in a test-driven way then that means that if a similar regression is made in the future in the codebase that there will be a clear failing test warning future developers that something is amiss. Git also has command, bisect which can be used to quickly find a problematic commit, by strategically checking out specific commits from the git history and then based on whether or not that commit is identified as being before or after the software regression was introduced then the next commit is either earlier or later in the git history until the culprit can be identified. Git bisect can be combined with automated testing to make the process of identifying the problematic commit even more efficient.
Walkthrough your code line by line. Try to read it with fresh eyes even if that means taking a 5 min break and revisiting. I'm always amazed how sleeping on a problem that stumped me usually makes a lot more sense in the morning. It's definitely possible for your mind to continue working through a problem even when you are not directly in front of a screen.
Look at the source code of the third-party package. check for open issues. If the error may be related to third-party software look at its source code. I’ve looked at React, misc. packages with types, Webmention, etc on GitHub to better understand their functionality and find relevant open issues. Oftentimes others may have encountered a similar issue.
Google is your best friend A quick search can be a developer’s best friend. Are you using a new function or package? Can you find an example where it's working? If you want to see code that uses the same APIs in context then recommend searching your local repo or https://grep.app to search open source repos.
Phone a friend. I recommend integrating git blame into your development environment I use the Git lens plugin which shows you, directly within files in a code editor, who authored certain file changes and the PR which can be helpful for quickly getting more context regarding decisions by looking at the associated Pull Request or having the opportunity to connect directly with the committer. Pair programming can be an effective way to debug and share knowledge. Similar, to the magic of figuring out the solution to a bug in the shower or overnight there is a phenomenon called rubber ducky debugging in which just explaining the issue to someone else (even an inanimate rubber duck) can help make the solution more obvious.

Once you’ve sorted out a gnarly or even an "obvious" in hindsight bug remember to document your learnings. Even if it’s just a quick note for your future self.

How to Add Instagram Timeline To a NextJS Site

Monica Powell — Thu, 08 Apr 2021 00:00:36 +0000

I recently added an Instagram timeline to my site In Digital Color and wanted to share how I added the Instagram integration to my NextJS site and document some of the hiccups I encountered along the way with authentication.

Screenshot of Instagram Timeline integration on indigitalcolor.com

Install and import `instagram-web-api`

We'll use the instagram-web-api npm package to do the heavy lifting for the integration. which should be installed within a NextJS site with npm install instagram-web-api or yarn add instagram-web-api. Once the package is successfully installed it should be imported into index.js file (or whichever page you would like the Instagram feed to appear on) with:

import Instagram from "instagram-web-api"

At this point the index.js file where I imported instagram-web-api looks like this:

import Instagram from "instagram-web-api"
import Layout from "../components/layout"

export default function Index() {
  return <Layout>{/*Other Page Content*/}</Layout>
}

Setup getStaticProps to Fetch Data at Build Time

Next, we need to set up a way to get fetched data into our component. In this case, I chose to use the async getStaticProps function to pass data into our component.getStaticProps is a function available to pages within NextJS that allows data to be fetched at build time and passed into page-level components.

import Layout from "../components/layout"
import Instagram from "instagram-web-api"

// empty array of instagram posts is being
// passed as a prop into the Index component
export default function Index({ instagramPosts }) {
  return <Layout>{/*Other Page Content*/}</Layout>
}

export async function getStaticProps(context) {
  // set posts to an empty array as a placeholder
  let posts = []
  return {
    props: {
      // return the posts as the prop instagramPosts
      // for the Index function to use
      instagramPosts: posts,
    },
  }
}

Setup Instagram Client Authentication

Before we can retrieve data from Instagram we should set up authentication instagram-web-api in getStaticProps() to be able to fetch data from Instagram. We can accomplish this by setting up a new Instagram client with new Instagram({username: IG_USERNAME, password: IG_PASSWORD}) and attempting to log in with await client.login()

export async function getStaticProps(context) {
  // create a new client to communicate with  Instagram
  // this service requires authentication
  //with username and password parameters
  const client = new Instagram({
    username: process.env.IG_USERNAME,
    password: process.env.IG_PASSWORD,
  })

  let images = []
  try {
    // attempt to log in to Instagram
    await client.login()
  } catch (err) {
    // throw an error if login to Instagram fails
    console.log("Something went wrong while logging into Instagram", err)
  }

  return {
    props: {
      instagramPosts: images,
    },
  }
}

Credentials such as the password should be accessed via environment variables that are only available locally and at build time to avoid exposing this information. In NextJS, local environment variables can be accessed by creating a file entitled .env.development.local. Although the username is not a secret you can add it to the environment file if you'd like. env.development.local should be added to your .gitignore file to avoid committing it to version control. Separately, I set up my hosting to have access to the appropriate secrets at build time which supersedes the values in the .env file.

My env.development.local file looks like this:

IG_USERNAME="super_cool_username"
IG_PASSWORD="super_secret_secure_password"

In addition to the env.development.local at a minimum you should have a .env file that sets the defaults for env variables. My .env file looks like and is checked into version control:

IG_USERNAME=""
IG_PASSWORD=""

Confirm Instagram Client is Functional

If you're not already you should run the development server of your NextJS site with npm run next and check in the terminal that is running the server to see if there are any console errors. You might encounter the error log we added of "Something went wrong while logging into Instagram" during this stage of the process.

Resolving 4xx Authentication Errors

While I was setting up the Instagram client with the correct credentials I encountered various 4xx authentication relates errors (if you're not familiar with HTTP status codes check out my site https://www.httriri.com/) being returned to Instagram saying "Please wait a few minutes before trying again". I was able to temporarily circumnavigate the 4xx errors and "Please wait a few minutes before trying again" message by switching my IP address with a VPN (Virtual private network) and attempting to authenticate again. A VPN allows you to access the internet with a remote VPN server's IP address as opposed to your local IP address. This article shares other ways you can change your IP address. I already had a VPN configured on my computer so I found that to be the most straightforward solution in my case. Using a VPN to access the internet resolved the issues I was encountering as they were IP address level issues. You can check if your issues are IP level by trying to log into Instagram manually on the same IP address and on another device that is connected to a separate cellular network (and has its own IP). I am wondering if there's a more official way to get Instagram to recognize API usage as not being unusual activity. If you are running into a 4xx error for a different reason this is a good time to manually confirm that the credentials you are providing are correct.

Request Timeline Data from Instagram

Once authentication is successful we can request specific data from Instagram calling client.getPhotosByUsername({username: process.env.IG_USERNAME}) to fetch timeline data for the username that is passed in.

export async function getStaticProps(context) {
  const client = new Instagram({
    username: process.env.IG_USERNAME,
    password: process.env.IG_PASSWORD,
  })

  let posts = []
  try {
    await client.login()
    // request photos for a specific instagram user
    const instagram = await client.getPhotosByUsername({
      username: process.env.IG_USERNAME,
    })

    if (instagram["user"]["edge_owner_to_timeline_media"]["count"] > 0) {
      // if we receive timeline data back
      //  update the posts to be equal
      // to the edges that were returned from the instagram API response
      posts = instagram["user"]["edge_owner_to_timeline_media"]["edges"]
    }
  } catch (err) {
    console.log(
      "Something went wrong while fetching content from Instagram",
      err
    )
  }

  return {
    props: {
      instagramPosts: posts, // returns either [] or the edges returned from the Instagram API based on the response from the `getPhotosByUsername` API call
    },
  }
}

Render Instagram Data with InstagramFeed component

Once we've successfully received timeline data back from the getPhotosByUsername() call we can render this data. Below is the skeleton I used to transform the data returned from the Instagram API into a digestible and visually engaging component that displays recent photos and links to them on Instagram so that visitors can click through to the actual posts.

import Link from "next/link"

export default function InstagramFeed({ instagramPosts }) {
  return (
    <>
      <h2>
        <a href="https://www.instagram.com/yourinstagramhandle/">
          Follow Us on Instagram
        </a>
        .
      </h2>

      <ul>
        {/* let's iterate through each of the
         instagram posts that were returned
         from the Instagram API*/}
        {instagramPosts.map(({ node }, i) => {
          return (
            // let's wrap each post in an anchor tag
            // and construct the url for the post using
            // the shortcode that was returned from the API
            <li>
              <a
                href={`https://www.instagram.com/p/${node.shortcode}`}
                key={i}
                aria-label="view image on Instagram"
              >
                {/* set the image src equal to the image
                url from the Instagram API*/}
                <img
                  src={node.thumbnail_src}
                  alt={
                    // the caption with hashtags removed
                    node.edge_media_to_caption.edges[0].node.text
                      .replace(/(#\w+)+/g, "")
                      .trim()
                  }
                />
              </a>
            </li>
          )
        })}
      </ul>
    </>
  )
}

In order to actually render this component and the associated post data from Instagram we need to import InstagramFeed into index.js and render it withing the Index component wiith the instagramPosts prop we received from getStaticProps.

import Layout from "../components/layout"
import Instagram from "instagram-web-api"
import InstagramFeed from "../components/instagramFeed"
// empty array of instagram posts is being
// passed as a prop into the Index component
export default function Index({ instagramPosts }) {
  return (
    <Layout>
      {/*Other Page Content*/}
      <InstagramFeed instagramPosts={instagramPosts} />
    </Layout>
  )
}

If everything worked properly you should now see all of your latest Instagram posts rendered on the page and be able to click any given posts to be taken to it on Instagram. If you are not seeing any posts rendering there may have been an issue with authentication (invalid credentials or rate limited by Instagram). If so, I recommend following my above troubleshooting steps of manually verifying credentials (in case of invalid credentials) or exploring using a VPN (if your IP address has been rate limited).

Creating Protected Routes In NextJS With Supabase

Monica Powell — Wed, 07 Apr 2021 23:54:11 +0000

This articles walks through how to create protected routes on NextJS with Supabase's user management. It assumes you already have a NextJS site up and running with the ability to create new Supabase users but if not check out the first part of this series on creating new Supabase users in NextJS

Supabase Auth Overview

Supabase has various methods in their JavaScript client library to handle user authentication and uses JSON Web Tokens (JWT) under the hood to manage authentication. If you want to learn more about how Auth works in Supabase check out the Supabase auth deep-dive video series. In order to have protected routes on our NextJS site, we'll need a way to register and authenticate users. We can perform these user actions and checks with the following methods from the Supabase Auth client. :

supabase.auth.signUp - We should give users the ability to create an account (covered in the first article on creating new Supabase users in NextJS)
supabase.auth.signIn - We need to give users the ability to sign-in. In this particular article, we'll cover the traditional method of using a username and password for sign-in but Supabase also supports other ways to log in, including OAuth providers (GitHub, Google, etc.) and magic links.
supabase.auth.user - We need a way to determine if a user is currently logged-in in order to ensure that logged-out users are not able to view pages that should only be accessible to logged-in users and that the proper information is displayed in various places like the site navigation.
supabase.auth.signOut - We should give users the ability to sign out and unauthenticate their session.

Create Protected Route

In order to create a protected route we need to have a particular page component we'd like to protect. For this example let's created a protected page at pages/protected.js that we can view at localhost:3000/protected when our site is running locally. This protected page will make a fetch request to a getUser API route to determine if there is currently an authenticated user loading the page. The API call should return the current user when there is one. We can then use this API response to redirect the page to the login page when there is no current user and only display user-specific information on the protected route when there is a user.

The API request can be made with getServerSideProps() which is a NextJS function that is called before a page renders. This allows us to redirect before the page renders based on the response from the getUser API call.



import { basePath } from "../utils/siteConfig";

export async function getServerSideProps() {
    // We need to implement `/api/getUser` by creating 
    // an endpoint in `pages/api` but for now let's just call it
  const response = await fetch(`${basePath}/api/getUser`).then((response) =>
    response.json()
  );

  const { user } = response;

 // If the `getUser` endpoint doesn't have a user in its response
 // then we will redirect to the login page
 // which means this page will only be viewable when `getUser` returns a user.

  if (!user) {
    return {
      redirect: { destination: "/login", permanent: false },
    };
  }
  // We'll pass the returned `user` to the page's React Component as a prop
  return { props: { user } };
}
export default function Protected({ user }) {
  return (
          <p>
          // Let's greet the user by their e-mail address
            Welcome {user.email}!{" "}
            <span role="img" aria-label="waving hand">
              👋🏾
            </span>{" "}
          </p>{" "}
          You are currently viewing a top secret page!
  );
}

In this instance, NextJS requires absolute paths for the API routes and if you do not have an absolute route then you'll receive the following error:
"Error: only absolute urls are supported". In order to resolve this I created a helper function in utils/siteConfig to set the basePath based on the environment. In order for this to work there needs to be a PRODUCTION_URL set in your deployed site's environment variables.



const dev = process.env.NODE_ENV !== "production";
export const basePath = dev ? "http://localhost:3000" : process.env.PRODUCTION_URL;

Now, we need to actually implement the getUser API route that the protected route is calling by creating a file pages/api/getUser.js. Within this file we will make a request to supabase.auth.user() which returns the current user when there is a user currently logged-in.



import { supabase } from "../../utils/supabaseClient";

export default async function getUser(req, res) {
  const user = await supabase.auth.user();
  return res.status(200).json({ user: user });
}

The above code assumes that you've already set up a Supabase Client which we covered in the first post of this series. The Supabase client we are using in this instance looks like the below and uses environment variables to determine the Supabase DB URL and associated key:



import { createClient } from "@supabase/supabase-js";

const supabaseUrl = process.env.SUPABASE_URL;
const supabaseKey = process.env.SUPABASE_KEY;

export const supabase = createClient(supabaseUrl, supabaseKey);

You can retrieve the API key and database URL associated with your Supabase project from https://app.supabase.io/project/yourprojecturl]/settings/api which can be navigated to by going to your project > settings > API.

a screenshot of the Supabase settings page

Sign-in and Redirect to Protected Page

We'll allow folks to log in and log out of the site using the sitewide navigation. In order to show the appropriate links based on authentication status, we can use the state to track if a user is currently authenticated. As a default, we'll set authentication status to false so that the navigation defaults to thelogged-out view.

When a user is authenticated then we will show the Sign Out text in the nav:

If there is no authenticated user then we will link to the Sign-in and Sign Up pages:



import Link from "next/link";
import { useEffect, useState } from "react";

export default function Header() {
  const router = useRouter();
  // Let's use state to track if a user is currently authenticated
  // As a default we'll set this value to false so that the navigation defaults to thelogged-out view
  const [isAuthed, setAuthStatus] = useState(false);

 // We'll set up the nav, on mount to call the getUser endpoint we just 
 // created to determine if a user is currently logged-in or not
  useEffect(() => {
    fetch("./api/getUser")
      .then((response) => response.json())
      .then((result) => {
        setAuthStatus(result.user && result.user.role === "authenticated");
      });
  }, []);

  return (

      <nav>
        <div>
        // If user is authenticated then we will show the Sign Out text
          {isAuthed ? (
            <span>
              <h3>Sign Out &rarr;</h3>
            </span>
          ) : (
              // If there is no authenticated user then we will link to the Sign-in and Sign Up pages
            <>
              <Link href="/signup">
                <h3>Sign Up &rarr;</h3>
              </Link>
              <Link href="/login">
                <h3>Login &rarr;</h3>
              </Link>
            </>
          )}
        </div>
      </nav>
  );
}

When a user clicks "Sign In" from the nav we will navigate the user to the login page which contains a form to allow users to sign-in. The form will collect a user's email and password and on submit will fire a function signInUser which makes an API request to an API route for login and passes the email and password values from the form submit event to the API. If all goes well then we will receive a user object and can redirect (using NextJS's client-side router) to the /protected route that serves as a landing page for logged-in users.



import { useRouter } from "next/router";

export default function Form() {
  const router = useRouter();
  const signInUser = async (event) => {
    event.preventDefault();

    const res = await fetch(`/api/login`, {
      body: JSON.stringify({
        email: event.target.email.value,
        password: event.target.password.value,
      }),
      headers: {
        "Content-Type": "application/json",
      },
      method: "POST",
    });

    const { user } = await res.json();
    if (user) router.push(`/protected`);
  };

  return (
    <form onSubmit={signInUser}>
      <label htmlFor="email">Email</label>
      <input
        id="email"
        name="email"
        type="email"
        autoComplete="email"
        required
      />
      <label htmlFor="password">Password</label>

      <input
        type="password"
        id="password"
        name="password"
        required
      />
      <button type="submit">Login</button>
    </form>
  );
}

The login API route will use supabase.auth.signIn to sign-in a user. If a user is successfully signed in then the API will return a 200 response, or else the API will return a 401 response. The form is not yet set up to handle this 401 response but ideally, we'd want to return some type of message to the user informing them that their credentials were invalid and prompt them to attempt to sign-in again or reset their password. However, as this app is currently being built the functionality to reset password does not yet exist so this error path cannot be fully handled yet.



import { supabase } from "../../utils/supabaseClient";

export default async function registerUser(req, res) {
  const { email, password } = req.body;
  let { user, error } = await supabase.auth.signIn({
    email: email,
    password: password,
  });
  if (error) return res.status(401).json({ error: error.message });
  return res.status(200).json({ user: user });
}

Sign Out and Redirect to Homepage

Let's update the Sign Out link in the header to be functional by creating a signOut function that fires on click of the Sign Out text.



<span onClick={signOutUser}>
   <h3>Sign Out &rarr;</h3>
</span>

We'll also want to import a router from next/router to handle our client-side redirect.



import { useRouter } from "next/router";

For signOutUser let's make a call to a logout API route that sets the authStatus to false when a user is successfully signed out. We also want to ensure that when a user is not logged-in they are not viewing an authenticated page by redirecting to the homepage if a user logs out on a page other than the homepage. Without explicitly redirecting to the homepage when a user signs out, the state of authStatus would change in the nav as well as the logged-in vs.logged-out specific text however, the actual page regardless of authentication would continue showing protected information for unauthenticated users which we don't want.



  const signOutUser = async () => {
    const res = await fetch(`/api/logout`);
    if (res.status === 200) setAuthStatus(false);
    // redirect to homepage when logging out users
    if (window.location !== "/") router.push("/");
  };

Now we need to create the /api/logout route so that we can actually use it when the signOutUser function fires.



import { supabase } from "../../utils/supabaseClient";

export default async function logoutUser(req, res) {

  let { error } = await supabase.auth.signOut();

if (error) return res.status(401).json({ error: error.message });

  return res.status(200).json({ body: "User has been logged out" });

}

Summary

So in conclusion, we created a protected route by creating a page component in NextJS that calls a getUser endpoint in getServerSideProps() and redirects to the log in page, instead of loading the protected route, when there is not a user returned. We also set up client-side routing to redirect users to /protected when they successfully logged-in and to the homepage / when they logged out. The core functionality to update and check authentication was handle in API routes using Supabase's various auth methods (signIn, signOut, user).

Example Code on GitHub

You can view the full source code for the example code at: https://github.com/M0nica/protected-routes-with-supabase-nextjs-example

Looking Ahead

I am looking forward to sharing more about the app development as I progress through my journey of developing Shine Docs . As I wrap up the authentication for this site I am considering adding additional functionality like magic links or other auth providers, which are natively supported by Supabase. Before I extend the auth functionality to support additional ways of authenticating I will need to update the site to give users the ability to reset their own password and better handle authentication errors to ensure that the sign-in (are the user credentials invalid? did something go wrong during sign-in?) and sign up (has an e-mail already been claimed? is a password not secure enough?) flow are as seamless as possible.

Creating New Supabase Users In NextJS

Monica Powell — Wed, 07 Apr 2021 23:50:54 +0000

This article is the beginning of a series about setting up a NextJS with Supabase for user management and database storage. View the next part of this series: creating protected routes with NextJS and Supabase

This article walks through how to create new users for a Supabase database with an API written in NextJS. Note: at the time of this writing that Supabase is free for beta users which is pretty nifty as they include a hosted Postgres database which makes it faster to get an application up and running with a functional database. After the Beta period wraps up Supabase is planning on charging for hosting and will offer current Beta users 1 year of base tier usage for free.

I am currently building a SaaS (Software as a Service) website along with some other Egghead folks who are creating different types of SaaS applications. I am building this app from "scratch" and am currently in the phase of setting up authentication. For this project I am focused on learning new technology and documenting my learnings therefore I decided to try out Supabase, which is an Open Source alternative to Google's Firebase. The specific application I am working towards building is, Shine Docs which will allow folks to document professional achievements in a granular way.

Here's a blurb from the project's README:

[...]your place to shine, showcase and document more granular professional (or otherwise) achievements. Did you fix a gnarly production bug in record time? Did you give your 1st (or 20th) conference talk? Did you write out some solid documentation? Make sure you capture all of this awesomeness in more in a dedicated space. These types of receipts translate well into future resumes, negotiations, annual reviews and reminders to yourself. Inspired by Julia Evan’s article on getting your work recognized with a brag document.

This application is intended for folks looking for more structure with how they document granular professional achievements as well as those looking to have their achievements be more visible.

Set Up NextJS

If you do not yet have a NextJS site you should set up a boilerplate NextJS site as a starting point. This can be done by running the command npx create-next-app to spinup up a default NextJS site. After going through the prompts you should open your newly created directory containing the site.

The next step in setting up NextJS to interact with Supabase is to install Supabase dependencies with @supabase/supabase-js and then run yarn dev to run the site locally. If everything worked out you should be able to visit localhost:3000 and see your Next site running.

Set up Supabase Project

On Supabase we will create a new project and then retrieve the API key and URL from https://app.supabase.io/project/yourprojecturl]/settings/api which can be navigated to by going to your project > settings > API.

a screenshot of the Supabase settings page

In order for our application to be able to interact with our project's DB we will use environment variables to store the necessary values. As a Mac user, I tend to store environment variables in ~/.bash_profile.

You can add the following your ~/.bash_profile or wherever you store local environment variables:

export SUPABASE_KEY="SUPABASEKEYFROMSETTINGSSCREEN"
export SUPABASE_URL="SUPABASEURLFROMSETTINGSSCREEN"

If you already have a terminal session running then after you save your environment variables you should run source ~/.bash_profile to ensure that the newly exported environment variables are available to your NextJS app to access.

We will then create a supabaseClient.js file (in utils/) to set up the Supabase client that is used to interact with Supabase DB to use the URL and API key that were set in the previous step.

import { createClient } from "@supabase/supabase-js"

// retrieving environment variables
const supabaseUrl = process.env.SUPABASE_URL
const supabaseKey = process.env.SUPABASE_KEY

export const supabase = createClient(supabaseUrl, supabaseKey)

Having the Supabase client live in a standalone file will be helpful when we have multiple API endpoints that interact with Supabase that require the same credentials.

Registering Supabase User

Now we will call Supabase to register users by creating a new API function inside of pages/api that uses our Supabase client.

import { supabase } from "../../utils/supabaseClient"

export default async function registerUser(req, res) {
  // destructure the e-mail and password received in the request body.
  const { email, password } = req.body

  //make a SignUp attempt to Supabase and
  // capture the user (on success) and/or error.

  let { user, error } = await supabase.auth.signUp({
    email: email,
    password: password,
  })
  // Send a 400 response if something went wrong
  if (error) return res.status(401).json({ error: error.message })
  // Send 200 success if there were no errors!
  // and also return a copy of the object we received from Supabase
  return res.status(200).json({ user: user })
}

You can learn more about HTTP status codes on what different status codes mean on my site https://www.httriri.com/.

Now, let's actually use the Supabase endpoint to create users. Our site's visitors will fill out a form to register therefore let's create a form that requires an e-mail and password and calls the previously created Register endpoint upon form submission. This form will then be imported and used in our index file, index.js.

<form onSubmit={registerUser}>
  <label htmlFor="email">Email</label>
  <input
    id="email"
    name="email"
    type="email"
    autoComplete="email"
    required
  />
  <label htmlFor="password">Password</label>

  <input
    type="password"
    id="password"
    name="password"
    required
  />
  <button type="submit">Register</button>
</form>

Now let's define what happens onSubmit when registerUser is called by defining registerUser. This function will receive the email and password typed into the form from the form submission event and will make a post request to the register endpoint.

export default function Form() {
  const registerUser = async event => {
    event.preventDefault() // prevents page from redirecting on form submissiomn

    // call default function in pages/api/register
    // send the email and password from form submission event to that endpoint
    const res = await fetch("/api/register", {
      body: JSON.stringify({
        email: event.target.email.value,
        password: event.target.password.value,
      }),
      headers: {
        "Content-Type": "application/json",
      },
      method: "POST",
    })

    const result = await res.json()
  }

  return (
    <form onSubmit={registerUser}>
      // above form omitted for brevity
    </form>
  )
}

Now let's look at the response that we are getting back from the API request to the register endpoint.If we destructure res.json() like const { user } = await res.json() then we can see the user object for a successful request looks something like

user {
  id: '2de33395-b88b-4004',
  aud: 'authenticated',
  role: 'authenticated',
  email: 'test@example.com',
  confirmation_sent_at: '2021-03-09T12:35:02.895833829Z',
  app_metadata: { provider: 'email' },
  user_metadata: {},
  created_at: '2021-03-09T12:08:46.611304Z',
  updated_at: '2021-03-09T12:35:03.466491Z'
}

If we've received a 200 response (no errors!) and a user object back from our SignUp call to Supabase then we can redirect users to a message prompting them to confirm their e-mail address. We can use the NextJS router to handle this redirect:

import { useRouter } from "next/router"

export default function Form() {
  const router = useRouter()
  const registerUser = async event => {
    event.preventDefault()

    const res = await fetch("/api/register", {
      body: JSON.stringify({
        email: event.target.email.value,
        password: event.target.password.value,
      }),
      headers: {
        "Content-Type": "application/json",
      },
      method: "POST",
    })

    const { user } = await res.json()
    if (user) router.push(`/welcome?email${user.email}`)
  }

  return <form onSubmit={registerUser}>{/*ommitted for brevity*/}</form>
}

Now we are currently redirecting folks to a Welcome page that doesn't exist so let's create a new page page/welcome.js.

import Footer from "../components/footer";
import { useRouter } from "next/router";

export default function Welcome() {
  const router = useRouter();
  const { email } = router.query;
return (
      <main>
        <p>
          Thank you for signing up. Please check your {email} inbox to verify
          your e-mail address!
        </p>
      </main>
      <Footer />

    </div>

);
}

If all went well then if you fill out the form with an email address and password then you should be redirected to the welcome screen, receive a confirmation e-mail from Supabase to the e-mail you submitted and see under the Authentication section of your project at https://app.supabase.io/project/[yourprojecturl]/auth/users that there is a new user in your users table with the email address that you just submitted. By default Supabase is set up to not allow users to log in until they verify their e-mail address, so unless you've changed that setting you should see the column Last Sign In showing the value "Waiting for verification...".

Example Code on GitHub

Checkout out the example code for this article at: https://github.com/M0nica/register-supabase-users-nextjs-example

That's all I have for now! But I am looking forward to sharing more about how I implement Supabase as I continue my app development.

Set Yourself Up For Success During Hacktoberfest

Monica Powell — Sat, 03 Oct 2020 13:31:24 +0000

Throughout Hacktoberfest (October) people are encouraged to contribute to open-source to secure a t-shirt along with other swag. I have long been a fan of Hacktoberfest as some of my initial contributions to open-source software occurred during Hacktoberfest. Although, a downside to Hacktoberfest for some project maintainers is that people are encouraged to submit low-quality, spammy pull requests which directly increases the time required for them to maintain their projects without the benefit of being able to incorporate the code that was submitted [As of 10/03/2020 project maintainers must opt-in to participating in Hacktoberfest]. A lot of project maintainers for projects without large corporate funding are unpaid (or underpaid) volunteers.

As I've contributed to larger open-source projects and maintained smaller projects over the years I've learned more about what types of open-source contributions are generally accepted. I recently read through Working in Public by Nadia Eghbal (and shared my notes) which is a great primer if you are interested in learning more about the labor that goes into maintaining open-source software and norms for participating in various types of open-source communities. Below are some of my thoughts on how to make quality contributions to open-source during Hacktoberfest and beyond! I plan on updating this post over time.

1. Finding Issues

If you're newer to contributing and are looking for issues that are designed to be smaller in scope, instead of opening pull requests with unsolicited, 1 character changes, I'd recommend using GitHub's issues filter to search for "Hacktoberfest" or "Good First Issue" or checking out these sites that help people find beginner-level issues that you're interested in contributing to:

The benefit of spending the time to find issues that are well-scoped to your interest and experience level is that if you make an attempt at resolving an issue based on the requirements usually maintainers are more willing to work with you to help get your changes accepted into a project.

In addition to using the above resources to find good first issues, I'd also recommend contributing to projects you already use or check out the following projects:

awesome-uses • share your developer setup, gear, software and configs.
httriri: HTTRiRi - HTTP Status Codes as Portrayed by Rihanna GIFs ✨💄 • submit your favorite Rihanna GIF that accurately potrays a status code and improve an educational resource for those looking for an HTTP status code reference.
twilio-labs/open-pixel-art • Contribute to a fun, collaborative pixel art project to teach people how to contribute to open-source.
selfdefined/web-app: Dictionary database with future API and bot integrations • submit definitions and enhancements to the selfdefined dictionary.

Note: Hacktoberfest has been updated to require maintainers to opt-in to having contributions to their projects count towards Hacktoberfest. If you would like your contributions to count towards the Hacktoberfest requirements, explore the Hacktoberfest topic on GitHub to find projects that have explicitly opted-in to participating.

2. Claiming Issues

Different projects have different norms for indicating that someone is planning on working on an issue. As a starter, I would recommend commenting on any issues that you are interested in working on to reduce the chances of multiple people submitting duplicate changes to resolve the same issues. Generally, unless a maintainer already had someone in mind to work on an issue whoever "claims" an issue first and submits a pull request first will be prioritized and later submissions may be viewed as spammy. Also, note that not all issues are opened by project maintainers and core contributors so it's helpful to read the conversation and tags on an issue to determine if a maintainer is interested in resolving the issues that were raised in the issue.

3. Read the Documentation

I would recommend focusing on contributing to projects that have at least a basic README that outlines how to get started with contributing and what the expectations are for contributors. Another file that some repositories have to help provide more context for contributors is a
CONTRIBUTING.md which indicates what the expectations are for how people should contribute to a project. For example, for my project https://www.httriri.com/
I've shared guidelines for how files should be named and how to make changes that are more likely to be accepted (i.e, not submitting duplicate content, checking open issues before submitting unsolicited changes) in the README file to help make it easier for new contributors to get new status code submissions accepted:

The GIF should include Rihanna and not already be included on https://www.httriri.com/. In rare cases, a GIF that already exists in the HTTRIRI collection can be used for another status code but within the same set of proposed changes, a new GIF should be chosen for the other status code to ensure there are no duplicate images and the overall size of the collection is growing. Excerpt from HTTRIRI Documentation

If there are things specified within a repository regarding naming conventions, testing practices, where files should live, etc. these are usually requirements and not suggestions unless otherwise indicated. Therefore, it's in your best interest to follow those guidelines to hopefully have your changes accepted and to reduce the back and forth required to finalize your pull request.

4. Opening a Pull request

Once you feel like your changes adequately address an issue you should open a pull request in the repository. It's generally a best practice to reference the issue that you are resolving in your pull request and to add a link to your PR on the issue. Some projects will include a checklist or template when opening a new pull request, this generally should be filled out completely unless something is not applicable and gives you another chance to check that your contribution meets the requirements. For example, if a checklist indicates that unit tests should be updated or added for all changes then you should make sure that is done in your pull request and if not indicate why you have decided to forgo a particular requirement.

If you're not quite ready to submit a PR for feedback but need assistance I'd recommend opening a draft PR or sharing a link to your branch on the issue and requesting guidance from other contributors. Depending on the project they may indicate that other forums like Discord should be used to solicit help with contributing. Not all projects have the same capacity to help newer contributors, so you may have to ask for help from others that aren't necessarily directly involved in the project. For example, if you're contributing to a popular, React repository a project maintainer may not be able to answer a lot of follow-up questions but someone in a popular React Discord might be able to help you.

Summary

Overall, to increase the chance of your pull request being accepted I would recommend first identifying an open issue that a maintainer has already given the green light to be worked on, indicating that you are interested in that issue if it's still up for grabs and hasn't been claimed, reading through the project documentation and guidelines to make sure your contribution is aligned with their expectations for contributions and opening a pull request once you've completed the previous steps. I hope these tips help you get closer to successfully contributing to open-source software!

Best Practices For Keeping Server-Side Rendering Cool

Monica Powell — Sat, 12 Sep 2020 13:31:42 +0000

Server-side rendering can be powerful but it does require thinking in multiple contexts so it's important to be familiar with some of the common gotchas when developing Server-Side Rendered websites. This article is a written version of a talk I gave at React Rally 2020 on keeping Server-Side Rendering Cool with React Hydration, where I shared some helpful things to keep in mind to render a seamless experience as a Server-Side Rendered (SSR) site transitions from a window-less (server) environment to a browser.

What is Server-Side Rendering (SSR)?

Let's take a step back. First, what is server-side rendering? When a server generates the initial HTML that loads in a browser. Frameworks like NextJS and GatsbyJS support SSR out of the box. Server Side Rendered applications tend to initially load content faster and lead to higher SEO ranking than their Client-Side Rendered counterparts.

There are different types of server-side rendering for example server-side rendering can be used to render every single page request or only the initial page request. NextJS offers two forms of server-side rendering. You may be familiar with Create React App, a default React app boilerplate which does not come with SSR functionality configured out of the box.

What is Client-Side Rendering (CSR)?

In contrast to Server-Side Rendering, a website that only supports Client-Side Rendering requires visitors to have HTML enabled to view content on the site. Often visitors will see a largely blank page when visiting a Client-Side rendered application if they do not have JavaScript enabled.

If you look at the DOM in the developer tools of a Create React App (or client-side only rendered application) you'll notice very little HTML markup in the DOM. The markup might resemble something like the below code:

<html>
  <head>
    <!-- SEO/Metadata here -->
  </head>
  <body>
    <div>You need to enable JavaScript to run this app.</div>
    <div id="root"></div>
    <script>
      <!-- all of the JavaScript -->
    </script>
    <script src="/static/js/2.6158a3d8.chunk.js"></script>
    <script src="/static/js/main.ba831a9f.chunk.js"></script>
  </body>
</html>

Generally this markup will include the root where React is injected, a message saying you need to enable JavaScript to run the app as well as script tags that link to the JavaScript that needs to be loaded to hydrate the page.

Overview of SSR (in static context)

Let's walk through what happens in Server-Side Rendered applications like NextJS or Gatsby when all the pages for the site are statically generated at once in the server.

First, you write the site in React ⚛️ then Gatsby or Next (Static Site Generation) creates a production build of your site using ReactDOMServer, a React server-side API to generate HTML from React. When someone visits your website the first thing they'll see is the HTML generated from the server. JavaScript then loads after the initial page load and the ReactDOM.hydrate() API kicks in to hydrate the HTML page that was rendered from the server with JavaScript. After Hydration the React reconciler APIs take over and the site becomes interactive.

Toggling JavaScript: SSR vs. CSR

Let's compare how a Server-Side and Client-Side rendered applications appear when JavaScript is enabled or disabled. For these two examples, I used Gatsby and Create React App for these technologies.

The above image is of a Gatsby site, where when JavaScript is toggled on/off there is very little visible change aside from the image loading as most of the HTML was available without JavaScript.

In contrast, in the above image of a Create-React-App which uses client-side rendering and the browser is responsible for constructing the initial HTML. Due to this we just see the bare-bones HTML as opposed to a full HTML document when JavaScript is disabled.

My server-side app looks great in development...What could go wrong? 😅

We just looked at an example of Server-Side rendering that looked great in production both with or without JavaScript! What could go wrong? There are some common issues you might run into with Server-Side rendered applications that only occur during the initial hydration process in production such as layout shifts or errors that only appear at build-time.

1. Missing Data on Server-Side

Something helpful to keep in mind is that some data just is not available in the static server context like user or browser-specific data. For example, window size, authentication status, local storage, etc.

In the above image of Target's navigation, you'll see that the store location data, my name, and items in the shopping cart were not available on the initial page load. Once the data was available it hydrated on the page without shifting the layout. Loading patterns like this can be common on server-side rendered applications.

2. Unavailable JavaScript

Let's debug the above hydration issue that caused my site to have multiple unnecessary rendering changes during load. Something huge that is not available on initial load and can cause issues in server-side rendered applications is JavaScript! It's considered a best practice to load CSS before JavaScript therefore you need to consider how the HTML and CSS on a page load BEFORE JavaScript is available since JavaScript is not required for the page to load.

You may end up noticing weird changes on the initial page load that change too quickly to properly inspect - especially if you have a faster internet connection. But there are ways to slow down and really see what is going on. In particular, I'd recommend disabling JavaScript in your browser or using a site like web page test to generate film strip thumbnails that show you exactly how the page is loading step by step.

Above is the waterfall I took of the issue on my site before it was resolved. You can see one of the issues is that the size of the FontAwesome icons changes drastically between 96% and 99% loaded which can be a disjointing experience.

The solution for getting rid of the resizing of the icons during load involved replicating the final styling with local CSS and removing any dependency on FontAwesome's external CSS which required JavaScript to be available.

I disabled JavaScript which allowed me to see in development that the ways the icons look before they were fully loaded mirrored the app without JavaScript. This led me to realize Font Awesome was using its own styling that was coming in through JS that conflicted with my local CSS style. Since CSS loads before JS, disabling Font Awesome's external CSS (loaded via JavaScript) and replicating the CSS styles I wanted locally resolved the issue

You'll notice after (above image) removing the dependency on Font Awesome's CSS that the styling of the icons remains consistent as the application loads. I wrote an article with more information about my experience resolving the Font Awesome rendering issues.

3. Immutable Layout

The previous issue of changing styles is related to a much larger issue of handling layouts on the server-side. Generally, you should avoid unnecessary layout shifts during page load by implementing layouts with placeholder/gap for expected client-side content and avoiding using JavaScript to position or style content instead of CSS. It is common for some data to be unavailable as the page loads, however, you can develop in a way that can handle missing data by leaving room in the UI for the data to load. In the Target navigation example you can see there is no shift as the user/store specific data is loaded.

4. Strange Conditional Rendering in Server Context

If you write React you may have conditionally rendered content like the below code snippet based on screen size using the MatchMedia API. However, this approach might lead to some unnecessary frustration...

if (small) {
  return <MobileApp />
} else {
  return <DesktopApp />
}

The matchMedia() API can't reliably detect the browser or device size in the server context which can lead to some strange rendering issues as the page loads if the originally set media size doesn't match the actual browser.

It's preferable to use CSS or a library like fresnel which wraps all Media components in CSS instead of MatchMedia in Server-Side rendered applications to layout content. Since CSS loads before JS, styles applied via CSS, unlike JavaScript should visibly match what you expect on page load.

Below is an example of how Fresnel can be used. First, you need to import createMedia from Fresnel then define the breakpoints and export MediaContextProvider from the object created from createMedia to wrap the entire app. Then you can use Fresnel's Media component throughout your app to render components based on the predefined breakpoints.

import React from "react"
import ReactDOM from "react-dom"
import { createMedia } from "@artsy/fresnel"

const { MediaContextProvider, Media } = createMedia({
  breakpoints: {
    sm: 0,
    md: 768,
  },
})

const App = () => (
  <MediaContextProvider>
    <Media at="sm">
      <MobileApp />
    </Media>
    <Media greaterThan="sm">
      <DesktopApp />
    </Media>
  </MediaContextProvider>
)

ReactDOM.render(<App />, document.getElementById("react"))

The final step is inject the CSS in the server by passing mediaStyle into a <style> tag in the head of the document so that CSS can be generated from fresnel markup and be rendered on the server. You can read more about setting up Fresnel for SSR in the Fresnel docs.

5. Error: Window is undefined

If you attempt to access browser-specific elements in a server context JavaScript will not be able to resolve those elements.

When building a site you might run into the window is undefined or document is undefined error. This happens when logic within an app assumes the browser window is defined in a server and reference browser-specific elements in the server.

Your first inclination to resolve the undefined Window error might be to write something like:

typeof window !== undefined ? //render component : // return null

However, if your app is using the ReactDOM.hydrate API to transform the site from HTML to the virtual DOM you need to be aware of ReactDOM.hydrate's constraint. ReactDOM.hydrate():

👯‍♂️ expects that the rendered content is identical between the server and the client.
🙅🏾‍♀️ does not guarantee that attribute differences will be patched up in case of mismatches.

The Hydrate API that converts HTML to full-fledged React expects that the content is always identical between the server and client and does not guarantee that matches will be patched up in case of mismatches. Due to this lack of guarantee, it is NOT a good idea to conditionally render based on elements that will differ between the server and client.

Check out this article by Josh W Comeau for examples of visual discrepancies that can occur when
React.Hydrate() fails to reconcile an unexpected difference.{" "}

Safely accessing browser elements enables you to
avoid reconciliation errors when ReactDOM.hydrates a site from HTML to React. In order to avoid issues with the hydration reconciliation process, you can wrap any side effects that rely on the Window or Document in a useEffect hook since that only fires after the component has mounted.

useEffect() Example:

function Example() {
  const [count, setCount] = state(0)
  useEffect(() => {
    document.title = `You clicked ${count} times`
  })
}

This is an example from the React Docs of referencing a browser element, document.title within useEffect(). This code will never be executed on the server as it executes after the React Virtual DOM is available and therefore avoids running into issues with React.Hydrate().

Rule of Least Power

With JavaScript comes great responsibility, sometimes JavaScript just isn't the right tool for the job:

"JavaScript is a powerful language that can do some incredible things, but it’s incredibly easy to jump to using it too early in development when you could be using HTML and CSS instead. Consider the rule of least power: Don’t use the more powerful language (JavaScript) until you’ve exhausted the capabilities of less powerful languages (HTML)." - Iain Bean, Your blog doesn’t need a JavaScript framework

I recently used the rule of least power to speed up the initial load time of my header and eliminate relying on JavaScript to dynamically load different headers images on my site based on screen size.

I was looking into how to display different images based on screen size and stumbled up HTML art direction which can be used to dynamically load images based on the screen size using HTML srcset attributes instead of JavaScript. Swapping images at different screen sizes can be done with JavaScript or CSS instead of native HTML attributes however using HTML can improve page loading performance as it prevents unnecessarily preloading two images.

The cool thing about the HTML approach is that it can improve page loading performance as it allows the browser to only preload the image that is visible within the viewport. This can be especially beneficial if you need to display multiple images at various places within a site depending on the screen size.

<picture>
  <source media="(min-width: 625px)" srcset="animonica-full.png" />

  <source srcset="animonica-headshot-cropped.png" />

  <img src="animonica-full.png" alt="Illustrated Monica" />
</picture>

In order to set up this functionality in HTML you can use the picture attribute and set media queries on each source image. It will return the first condition the is true and as a fall back it'll return the image from the img tag.

It's also possible to use the art-direction API in Gatsby with gatsby-image which is Gatsby's package for loading and transforming images from GraphQL. I wrote an article with more information about my exploration into using art direction with Gatsby.

Summary

In a Server-Side Rendered context it's important to consider how the page loads both when data is and is not available.
CSS is the right tool for handling layout, especially in a Server-Side Rendered Application. Using JavaScript for styling in SSR apps can lead to strange loading experiences for some users.
It's important to guard references to browser-specific elements like document or window within useEffect() to avoid reconciliation error as the page hydrates to transform SSR apps from HTML to React.

Resources & Further Reading

Below are some resources I recommend if you're looking to further explore the rendering process for server-side rendered React applications.

How to Make Your VSCode Sparkle

Monica Powell — Sat, 12 Sep 2020 13:17:46 +0000

This article shows you how to customize your VSCode set up to display animated sparkles while you are typing. There's a VSCode extension, Power Mode that adds animated flair while you're typing. It has a few different default animations but none of them quite sparkle.

Above is a GIF of animated sparkles in my VSCode. The editor's theme is Night Owl and the font is Dank Mono. You can learn more about my VSCode setup on my uses page.

If you're not using VSCode, check out these Power Mode extensions for various code editors. The implementation of each differ but some of them support customized animations.

Enable Power Mode Extension

In order to add animations to your VSCode first you need to install Power Mode
and enable it by updating your VSCode settings to include the following:
"powermode.enabled": true.

Depending on your operation system the VSCode settings file is located here:

Windows - %APPDATA%\Code\User\settings.json
macOS - $HOME/Library/Application Support/Code/User/settings.json
Linux - $HOME/.config/Code/User/settings.json

Customize Power Mode

"powermode.enabled" turns on the extension's default animations when you're typing but if you want sparkles then some additional customization is required.
In particular, you need to configure "powermode.customExplosions" in settings and pass in your own animation to be used for the explosions. This setting supports base64 encoded gifs, absolute file path, or https image URLs.

 "powermode.customExplosions": [
// absolute path to custom ✨ GIF on my computer
    "/Users/monica/Dev/power-mode-sparkles/sparkles.gif"
  ],

If you are interested in other animation ideas aside from sparkles check out the vscode-power-mode/Help wanted: explosion gifs issue on GitHub. In fact, this issue is where I found the image for my sparkles ✨ thanks to federicca. You can download the Sparkle GIF I used for my configuration.

My Final Power Mode VSCode Configuration

My VSCode settings.json includes the following keys and values after configuring Power Mode:

// turn on powermode 🚨
"powermode.enabled": true,
  "powermode.customExplosions": [
// absolute path to custom ✨ GIF on my computer
    "/Users/monica/Dev/power-mode-sparkles/sparkles.gif"
  ],
  // enableShake is true by default which causes the
  // text/screen to shake, the following line disables that
   "powermode.enableShake": false,
  // tweaking settings to reduce amount of explosions
  "powermode.maxExplosions": 1,
  "powermode.explosionFrequency": 4,
  //backgroundMode mask - animation matches the current syntax color
  //backgroundMode image - displays animation with original colors from the image
  "powermode.backgroundMode": "mask",

Optimizing Power Mode

Power Mode recommends tweaking some of the default settings to reduce the frequency of animations if the extension is causing your editor to slow down.

Sparkle GIF to Download

Right-click and save the below image to your computer if you're ready to start adding more sparkles to your development workflow.

6 Transformative Tech Conference Talks

Monica Powell — Sun, 06 Sep 2020 11:51:37 +0000

Here's a round-up of some of my favorite conference talks that have shaped the way that I think about web technologies, the workplace and community organizing. I hope some of these talks will also cause you to reflect and in some ways become a better technologist.

Glue Talk by Tanya Reilly

I had the pleasure of hearing Tanya Reilly give this talk at a Write/Speak/Code event in NYC. She walks through how to approach "the less glamorous - and often less-promotable - work that needs to happen to make a team successful" through a strategic lens. Often the burden of performing less-promotable work falls on the shoulders of marginalized folks within technology. Her talk is an actionable guide to navigating conversations with your manager to ensure you're contributing to the type of projects that will be recognized and reduce the chance of any surprises during formal reviews. I (unfortunately) have had to recommend this talk to a lot of women in technology who have experienced being delegated to do a significant share of glue work. You can check out the slides and sketch notes on Tanya's site: https://noidea.dog/glue.

JavaScript is AsynchroWAT? By Crystal Martin

Crystal Martin breaks down how asynchronous JavaScript works. I feel like this is a topic that a lot of folks new to JavaScript may have difficulty understanding and Crystal assures folks that don't yet fully understand asynchronous JavaScript that they're not alone. I found her talk very relatable and informative. I especially appreciated her bring in examples of an intense (hair) wash day to describe how JavaScript functions work.

How to Build a Magical Living Room by Saron Yitbarek

Saron Yitbarek, the founder of CodeNewbie is not only a prolific podcaster but also a phenomenal community organizer and one of my heroes! Her keynote at RubyConf is a master class in building inclusive communities. Saron shares what she's learned about building a magical living room to make people feel like they're welcome in your community. You'll walk away from this talk with actionable advice for becoming a stronger community leader.

Tautology and Business Value Presented by Heidi Waterhouse

Heidi presented this talk at You Got This 2020: From Home. I was able to see a live version at Adulting.dev. Heidi talks through how to strategically understand your value within a business context. I think this talk is especially crucial for folks who have not worked through a recession and/or need additional resources and tips to advocate for themselves in the workplace.

Building a Custom React Renderer by Sophie Alpert

One of the coolest talks I've seen live was Sophie Alpert walking through how to use the npm package react-reconciler to you build your own React renderer. It inspired me to one day (far away) attempt to give a technical talk with just a text editor. I felt that I had a better understanding of the React reconciliation process after listening to her talk.

Let’s Program Like It’s 1999 by Lee Byron

Lee Bryon also gave a phenomenal talk at React Conf where afterward I felt like I traveled a bit through time. He provided an overview of how much the web has not changed over the last 20 years. As a JavaScript developer who has only dabbled in PHP, I found it especially fascinating to learn how many of the PHP and LAMP Stack abstractions and mental models have found their way into the modern JavaScript development ecosystem. More often than not developers discuss how rapidly web development changes so it was helpful for Lee to share some of the principles that have, so far, stood the test of time (a.k.a the past 30 years) through various technical implementations.

What conference talk has most inspired you? What's the most interesting presentation you've seen so far? Share your favorite conference talks with me on Twitter: @waterproofheart.

Adding Environment Variables To GitHub Actions

Monica Powell — Mon, 24 Aug 2020 14:32:29 +0000

This article walks through how to pass environment variables to GitHub Action Workflows. I recently set up GitHub actions on this site to automatically run unit tests whenever I open a new Pull Request to ensure that changes to the site were not introduction breaking changes to unit tests under the radar.

I ran into some hiccups when setting it up so that the workflow could install the Font Awesome dependency which requires an NPM token. I went through a few of my GitHub Actions build minutes while testing how to properly pass environment variables to my .github/workflow/test.yml file. Hopefully this article saves you some time and build minutes the next time you set up environment variables for GitHub Actions.

In order to setup my GitHub Action, I modeled my new GitHub Action workflow after similar functional workflows and expected everything to run smoothly. However, I merged the pull request with my changes and saw on the Pull Request that the step of the GitHub Action workflow that installed dependencies failed with the following error:

error An unexpected error occurred: "Failed to replace env in config: $
{FONTAWESOME_NPM_AUTH_TOKEN}"

And then I remembered 💡 my site requires an environment variable to build and deploy. Locally I have .npmrc file that sets up the the npm configuration to pass in the appropriate environment variable for my site and looks like:

@fortawesome:registry=https://npm.fontawesome.com/
//npm.fontawesome.com/:_authToken=${FONTAWESOME_NPM_AUTH_TOKEN}

In particular the GitHub Action workflow did not have access to the FONTAWESOME_NPM_AUTH_TOKEN which I have set in my local bash profile and passed into the .npmrc file. So I needed to give the GitHub repository that is running this actions access to the environment variable by going to its settings page. You can access settings by clicking "Settings" in the repository's navigation. The url to update secrets for a repository (at the time of this writing) looks like: https://github.com/username/repo/settings/secrets where username and repo should be replaced with the username and repo of the desired repository and clicking "new secret".

Above is a screenshot of what the secrets page under my repository settings looked like once I added the FONTAWESOME_NPM_AUTH_TOKEN.

Now, that my repository had access to the environment variable I needed to update each job within my action to also have access to the variables. Before adding the environment variable to my repository my GitHub Action the job that installed dependencies looked like:

 - name: Install Dependencies
      run: npm install

after adding the environment variable I updated the dependency installation job to:

- name: Install Dependencies
      run: |
        npm config set //npm.fontawesome.com/:_authToken=${FONTAWESOME_NPM_AUTH_TOKEN}
        npm ci
      env:
        FONTAWESOME_NPM_AUTH_TOKEN: ${{ secrets.FONTAWESOME_NPM_AUTH_TOKEN }}

npm config set allowed me to manually set the npm configuration outside of the .npmrc file and pass in the appropriate environment variable. I also updated npm install to npm ci which installs a project with a clean slate and is better suited for a CI environment. Finally after the run values I passed in a env key that contained FONTAWESOME_NPM_AUTH_TOKEN which referenced ${{ secrets.FONTAWESOME_NPM_AUTH_TOKEN }} a.k.a the secrets from this GitHub repository.

The full GitHub action workflow I ended up using to install all dependencies (including Font Awesome which required a token ) and running unit tests looked like the below. Note: the test command also needed access to the same environment variable and needed it to be set separately in order for the GitHub Action to succesfully run without running into the error we saw earlier with retrieving the environment variable.

name: CI

on:
# will run on all PRs that are opened or updated (synchronized)
pull_request:
  types: [opened, synchronize, reopened]

jobs:
test:
  name: Test
  runs-on: ubuntu-latest
  env:
    CI: true
  steps:
    - uses: actions/checkout@v2
    - name: Use Node.js 13.x
      uses: actions/setup-node@v1
      with:
        node-version: 13.x
    - name: Install Dependencies
      run: | # run multiple commands
        npm config set //npm.fontawesome.com/:_authToken=${FONTAWESOME_NPM_AUTH_TOKEN}
        npm ci
      env:
        FONTAWESOME_NPM_AUTH_TOKEN: ${{ secrets.FONTAWESOME_NPM_AUTH_TOKEN }}
    - name: Test
      run: | # run multiple commands
        npm config set //npm.fontawesome.com/:_authToken=${FONTAWESOME_NPM_AUTH_TOKEN}
        npm run test
      env:
        FONTAWESOME_NPM_AUTH_TOKEN: ${{ secrets.FONTAWESOME_NPM_AUTH_TOKEN }}

How To Create A GitHub Profile README

Monica Powell — Sat, 11 Jul 2020 12:42:47 +0000

GitHub recently released a feature that allows users to create a profile-level README to display prominently on their GitHub profile. This article walksthrough how to access this new feature. I'll also be sharing some fun GitHub profiles I've seen so far. I'd love it if you shared yours with me on Twitter @waterproofheart.
The header GIF shows what my README looks like at the time of this writing. You may notice I was recently selected to be GitHub star!

Why READMEs?

The GitHub profile-level README feature allows more content than the profile bio, supports markdown which means you can play around with the content more visually (Did someone say GIFs!?) and the README is significantally more visible as it is placed above pinned repositories and takes up as much space above the fold of the webpage as you like.

A solid README is a core-component of well-documented software and often encourages collaboration by sharing helpful context with contributors. In my opinion, a profile-level README seems like a great extension of a convention a lot of GitHub users are already familiar with. If you're looking to make project-level READMEs more awesome and helpful check out matiassingers/awesome-readme for resources and examples of compelling READMEs.

How do I create a profile README?

The profile README is created by creating a new repository that’s the same name as your username. For example, my GitHub username is m0nica so I created a new repository with the name m0nica. Note: at the time of this writing, in order to access the profile README feature, the letter-casing must match your GitHub username.

If you already have a project in a repo-named username/username and are interested in setting up a profile-level README, then I recommend either re-naming that repository or re-purposing the existing project's README based on what makes the most sense in your particular situation.

Create a new repository with the same name (including casing) as your GitHub username: https://github.com/new
Create a README.md file inside the new repo with content (text, GIFs, images, emojis, etc.)
Commit your fancy new README!
- If you're on GitHub's web interface you can choose to commit directly to the repo's main branch (i.e., master or main) which will make it immediately visible on your profile)
Push changes to GitHub (if you made changes locally i.e., on your computer and not github.com)

Fun READMEs

The GitHub README profiles are written in Markdown which means you aren't just limited to texts and links, you can include GIFs and images. Need to brush up on Markdown Syntax? Check out this Markdown Cheatsheet.

// Detect dark theme var iframe = document.getElementById('tweet-1281026687103168512-344'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1281026687103168512&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1281231777475026945-795'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1281231777475026945&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1281111778290786310-954'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1281111778290786310&theme=dark" }

If you're really ambitious you can use GitHub actions or other automation like bdougieYO or simonw to dynamically pull data into your README:

// Detect dark theme var iframe = document.getElementById('tweet-1281699715466199040-44'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1281699715466199040&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1281435464474324993-466'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1281435464474324993&theme=dark" }

Serverless functions can also be used to dynamically generate information (for example your current Spotify activity):

// Detect dark theme var iframe = document.getElementById('tweet-1282326538990563329-719'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1282326538990563329&theme=dark" }

I'm a huge proponent that folks should maintain a website they have complete ownership over (even if it's a no-code website solution) but this is tempting...

// Detect dark theme var iframe = document.getElementById('tweet-1281590275660537858-923'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1281590275660537858&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1265773172520914944-44'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1265773172520914944&theme=dark" }

I've been inspired by the creative READMEs I've seen so far and am looking forward to seeing all kinds of profiles in the upcoming months.

Exploring Art Direction to Dynamically Load Images

Monica Powell — Sun, 05 Jul 2020 20:03:43 +0000

While updating my homepage to include my newly-commission illustration from Aishwarya Tandon, I wanted to load different versions of the image based on screen-size in a performant way. For my header image, I use gatsby-image, an official GatsbyJS plugin that optimizes images that makes it straightforward to control how images are progressively enhanced on page load. One of my favorite built-in Gatsby image effects is traced SVGs, which renders an SVG tracing of an image, in a pre-determined color before the image fully loads. You can explore all of gatsby-image's built-in loading effects on the using-gatsby-image site.

The above GIF illustrates how gatsby-image transitions from traced SVG to the loaded image

While looking into how to load different images at different breakpoints without unnecessarily downloading files I discovered gatsby-image's built-in support for this feature which is known as art direction. Modern HTML can be used to dynamically load of images based on screen size using srcset attributes with <img> and <source> instead of JavaScript. Swapping images at different screen sizes can be done with JavaScript or CSS instead of native HTML attributes however using the HTML attributes can improve page loading performance as it prevents unnecessarily preloading two images when only one image from the srcset needs to be visible within the viewport on load.

The above GIF shows the transition between different images loaded with art direction within gatsby-image

All images that use the gatsby-image plugin need to be constructed using a GraphQL query. Below is a slightly modified version of the useStaticQuery() I used to load image files into gatsby-image's Img. Within useStaticQuery() I wrote two named queries mobileImage and desktopImage to load both versions of the image I wanted on mobile as well as the desktop.

import React from "react"
import { useStaticQuery, graphql } from "gatsby"
import Img from "gatsby-image"

const Avatar = () => {
  const data = useStaticQuery(graphql`
    query {
      mobileImage: file(
        relativePath: { eq: "animonica-headshot-cropped.png" }
      ) {
        childImageSharp {
          fluid(maxWidth: 300, quality: 100) {
            ...GatsbyImageSharpFluid_tracedSVG
          }
        }
      }
      desktopImage: file(relativePath: { eq: "animonica-full.png" }) {
        childImageSharp {
          fluid(maxWidth: 300, quality: 100) {
            ...GatsbyImageSharpFluid_tracedSVG
          }
        }
      }
    }
  `)

  const sources = [
    data.mobileImage.childImageSharp.fluid,
    {
      ...data.desktopImage.childImageSharp.fluid,
      media: `(min-width: 625px)`,
    },
  ]

  return <Img fluid={sources} alt="Illustrated Monica" />
}

export default Avatar

If you inspect my site's header using Dev Tools you'll notice there's two <picture> sections, one that includes the tracedSVGs that are generated by GatsbyImageSharpFluid_tracedSVG in the image query and another with the .png files.

The HTML that ultimately renders to load the .png files from the earlier use of gatsby-image resembles the below:

<picture>
  <source media="(min-width: 625px)" srcset="animonica-full.png" />
  <source srcset="animonica-headshot-cropped.png" />
  <img src="animonica-full.png" alt="Illustrated Monica" />
</picture>

The media attribute in the <source> elements, within <picture>, determines which image srcset is displayed. The first condition that is met will be displayed, in the case where neither media condition is true or the browser doesn't support the <picture> element it will return the <img> element from within the <picture>. You can view current browser compatability for <picture> at Can I use this?.

As a recap, within gatsby-image we can pass an array of images to generate HTML's art direction related attributes. Using this approach instead of CSS or JavaScript reduces the number of assets that need to be preloaded in the browser. My current Gatsby site, displays a complete HTML page from the server to the client on the initial load without requiring JavaScript therefore I've found it helpful to avoid delegating certain tasks to JavaScript that HTML/CSS can handle in a more performant way. I've written more about this topic in my article Less JavaScript Makes Font Awesome More Awesome.

The article was originally published at aboutmonica.com

Give Your CSS Superpowers with CSS Variables

Monica Powell — Sat, 23 May 2020 22:44:02 +0000

What are CSS variables?

CSS variables or CSS custom properties are a way to declare reusable values within a CSS project. CSS variables can greatly reduce the repetition of code and allow us to reference more semantically meaningful names throughout our stylesheets like "--accent-color" versus the actual value they represent "#b5838d".

Most modern browsers support CSS variables. If you need to know whether or not CSS variables are supported in a particular browser without a polyfill it's a best-practice to reference browser-compatibility specifications on sites like Can I Use? or MDN web docs.

Current CSS Variables Browser Support (Source: MDN Web Docs)

How to declare CSS variables

In order to use CSS variables you should create a CSS custom property, which is a string prepended with a double hyphen --. These properties are scoped and available based on their selector. Generally, it is recommended to make the selector the pseudoselector :root so that it will apply throughout an entire site. If you select a more specific selector then the scope of where you can access the value of the variable changes accordingly.

Below is an example showing 5 different CSS variables being declared to represent different colors within a stylesheet.

:root {
  --white: #fff;
  --accent-color: #b5838d;
  --dark-accent-color: #a6757f;
  --main-color: #6d6875;
  --dark-main-color: #56505f;
}

In order to access the these CSS values throughout our CSS we can use the var() method like var(--accent-color). The following example selects the element with the signup class and changes its background-color to #b5838d.

.signup {
  background-color: var(--accent-color);
}

Since the value of --accent-color is being set with a CSS variable if we later decide to change the value of var(--accent-color) we only have to change it in one place, where the variables value is declared. Once the value of the variable is updated its new value will automatically be reflected everywhere var(--accent-color) is referenced. Being able to change the color in one place for a multitude of unrelated elements that are only coupled by color is powerful.

The Power of CSS Variables

CSS variables allow you to quickly play around with a color scheme and tweak the same color everywhere it is referenced without having to do a find and replace. Additionally, setting up CSS variables can improve the developer experience when creating color schemes, as you can switch the variable declaration values between themes without having to explicitly change the values within the rest of the stylesheet.

The two screenshots below show the difference in appearance when one line in the CSS file is changed from --accent-color: orange; to --accent-color: #b5838d; which is used in two completely separate places -- on the card's border-top property and the background color for the signup button. This can be very useful as stylesheets grow and values are re-used throughout.

`--accent-color: orange;`	`--accent-color: #b5838d;`

Explore CSS variables!

Play around with the CSS variable values by editing the below Codepen to see CSS variables in action!

This article was originally published on www.aboutmonica.com. Head over there if you like this post and want to read others like it.

Forem: Monica Powell

Tips for Debugging Software like a Detective

How to Add Instagram Timeline To a NextJS Site

Install and import instagram-web-api

Setup getStaticProps to Fetch Data at Build Time

Setup Instagram Client Authentication

Confirm Instagram Client is Functional

Resolving 4xx Authentication Errors

Request Timeline Data from Instagram

Render Instagram Data with InstagramFeed component

Creating Protected Routes In NextJS With Supabase

Supabase Auth Overview

Create Protected Route

Sign-in and Redirect to Protected Page

Sign Out and Redirect to Homepage

Summary

Example Code on GitHub

Looking Ahead

Creating New Supabase Users In NextJS

Set Up NextJS

Set up Supabase Project

Registering Supabase User

Example Code on GitHub

Set Yourself Up For Success During Hacktoberfest

1. Finding Issues

2. Claiming Issues

3. Read the Documentation

4. Opening a Pull request

Summary

Best Practices For Keeping Server-Side Rendering Cool

What is Server-Side Rendering (SSR)?

What is Client-Side Rendering (CSR)?

Overview of SSR (in static context)

Toggling JavaScript: SSR vs. CSR

My server-side app looks great in development...What could go wrong? 😅

1. Missing Data on Server-Side

2. Unavailable JavaScript

3. Immutable Layout

4. Strange Conditional Rendering in Server Context

5. Error: Window is undefined

Rule of Least Power

Summary

Resources & Further Reading

How to Make Your VSCode Sparkle

Enable Power Mode Extension

Customize Power Mode

My Final Power Mode VSCode Configuration

Optimizing Power Mode

Sparkle GIF to Download

6 Transformative Tech Conference Talks

Adding Environment Variables To GitHub Actions

How To Create A GitHub Profile README

Why READMEs?

How do I create a profile README?

Fun READMEs

Exploring Art Direction to Dynamically Load Images

Give Your CSS Superpowers with CSS Variables

What are CSS variables?

How to declare CSS variables

The Power of CSS Variables

Explore CSS variables!

Install and import `instagram-web-api`