
The `aria-label` property can be extremely useful when used correctly. When used incorrectly, it can wreak havoc on speech-input user experiences. It's an easy mistake to make and luckily it's pretty easy to fix!

## What is the `aria-label` property?

As defined by the WAI ARIA 1.2 standards, [the `aria-label` property](https://www.w3.org/TR/wai-aria-1.2/#aria-label) "defines a string value that labels the current element". It has the same purpose as [the `aria-labelledby` property](https://www.w3.org/TR/wai-aria-1.2/#aria-labelledby), which references another element that labels the current element. The purpose of both of these properties is to provide an [Accessible Name](https://www.w3.org/TR/accname-1.1/#dfn-accessible-name) of the current element.

Related to these properties is the `aria-describedby` property, which references another element that describes the current element. The purpose of this property is to provide an [Accessible Description](https://www.w3.org/TR/accname-1.1/#dfn-accessible-description) for the current element. The Accessible Name should be short and concise, and the Accessible Description should be more verbose and complement the Accessible Name.

The Accessible Name is part of what screen readers use to announce elements to a user when they come into focus. A `<button>` with no `aria-label` and plain text between its opening and closing tags would have an Accessible Name that matches its plain text. That same `<button>` can have its Accessible Name overridden with something completely different using the `aria-label` property.

Use the next two example code snippets to compare how the same button sounds with and without an `aria-label`.

<CallOut id="example-1" title="Example 1: <button> with no aria-label" type="example">

The code:

```html
<button>OK</button>
```

The output:

<br />
<button>OK</button>

</CallOut>

<CallOut id="example-2" title="Example 2: <button> with an aria-label" type="example">

The code:

```html
<button aria-label="Confirm selection">OK</button>
```

The output:

<br />
<button aria-label="Confirm selection">OK</button>

</CallOut>

## Why does `aria-label` need to match the visible label?

First of all, an `aria-label` must match its element's visible label because there is a Level A WCAG Success Criterion that says so. [SC 2.5.3: Label in Name](https://www.w3.org/TR/WCAG21/#label-in-name) says:

> For user interface components with labels that include text or images of text, the name contains the text that is presented visually.

This means that the Accessible Name computed for an element should contain the text of the element's visual label. One best practice for this is to have the Accessible Name start with the visual label's text. So if a link contains the text "Learn more" and the author of that link wants to include more information about the link's purpose in the `aria-label`, a good practice is to start the `aria-label` with "Learn more".

If you're like me and my ADHD brain, you might need a little more reasoning than "the rules say so" to motivate you to follow the rules. A lot of people don't like being told what to do, and that's fine!

So why do we need to follow Success Criterion 2.5.3? It partially has to do with speech-recognition technology. As it turns out, the Accessible Name for elements is how speech-input users can interact with elements in a web page.

Referencing our two previous examples:

- A speech-input user can activate the button from [Example 1](#example-1) by saying "Click OK". This is because the Accessible Name for that button is "OK".
- A speech-input user cannot activate the button in [Example 2](#example-2) in the same way. This is because the Accessible Name for that button is "Confirm selection". If a speech-input user wanted to activate this button, they would have to say "Click confirm selection".

For speech-input users that rely on visual labels to come up with voice commands, there no way for them to know before speaking a command if the Accessible Name of an element differs from its visual label. They will have to speak a command and find out if it does or does not work. If a command doesn't work, they may retry a couple of times. And if the command actually does not work at all because the Accessible Name doesn't match the visual label, their energy has been wasted and they're also stuck.

## What happens when `aria-label` doesn't match the visible label?

As I wrote this article, I started to learn about Voice Control on Mac. I wanted to see if I could find a real world example of speech-input navigation being broken due to mismatched visual labels and accessible names. I found a couple of examples right on the Twitter home page.

Unfortunately, more than half of the main navigation links have accessible names that don't match their visual labels. Even in the cases where a link's `aria-label` began with the text in the visual label, I was not successful in activating those links with speech-input. I made countless attempts.

- Home: The `aria-label` for this link is dynamic. If there are unread tweets in a user's feed, then the `aria-label` reads "Home (New unread Tweets)". The "Click Home" command only activates this link if there are no unread tweets.
- Explore: The `aria-label` for this link is "Search and explore". Saying "Click Explore" does not activate this link.
- Notifications: The `aria-label` for this link is dynamic. If a user has 2 notifications for example, the `aria-label` is "Notifications (2 unread notifications)". The "Click Notifications" command only activates this link if a user has 0 unread notifications.
- Messages: The `aria-label` for this link is dynamic. If a user has unread messages from one other user, for example, the `aria-label` is "Direct Messages (1 unread conversation)". If there are no unread messages, the `aria-label` is "Direct Messages". The "Click messages" command does not ever work.

Here's a quick demo of me trying to activate the "Messages" link that shows on the home page of Twitter:

<iframe
  title="Voice Control Demo - Twitter Messages link"
  width="100%"
  height="350"
  src="https://www.youtube-nocookie.com/embed/FBiKOt-ipO0"
  frameBorder="0"
  allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
  allowFullScreen
></iframe>

## Are there other users that benefit from `aria-label` matching the visible label?

This article primarily focuses on the sighted speech-input user's experience, but there are other users affected by this issue as well. Think of a sighted screen reader user that comes across the `<button>` element in [Example 2](#example-2). It is presented by their screen reader as "Confirm selection, button", but the text in the button says "OK".

This can be a very confusing and stressful experience for the user. How can they be certain the issue is with the website and not their own action? We're imposing an extra cognitive load on the user to process the mismatched audio and visual experiences. There is also extra cognitive load required to first memorize the behavior, and then recall it the next time they come across the element.

It's not necessary or kind to do this to users. It's energy-draining, and energy is an extremely limited resource for all kinds of people who rely on accessible interfaces.

## How do I fix mismatched `aria-label`s and visual labels?

Now that you know mismatching `aria-label` and visual labels is harmful for speech-input users, how do you go about preventing that harm? First, I'd recommend reading [Playing with state](https://sarahmhigley.com/writing/playing-with-state/) by Sarah Higley and [Be Careful with Dynamic Accessible Names](https://adrianroselli.com/2020/12/be-careful-with-dynamic-accessible-names.html) by Adrian Roselli.

Second, think about whether or not you need to provide an `aria-label` for the element that differs from its visual label. Some cases that come to mind:

- Are there duplicate visual labels?
  - Your markup can generally be improved by ensuring all visual labels are unique. This is beneficial for screen reader navigation.
  - The speech recognition technology probably has a way to help the user choose which element they want. With Voice Control on Mac, a number appears next to the elements with matching Accessible Names after the command is spoken. Then you're able to say the number of the element you want to activate.
- Is the content of the element plain text? Omit the `aria-label` property. The computed accessible name for the element will be its text content.
- Is the element a toggle button? Reference the [Playing with state](https://sarahmhigley.com/writing/playing-with-state/) article I mentioned and also check out the [Toggle Buttons](https://inclusive-components.design/toggle-button/) writeup from Inclusive Components. The `aria-pressed` property better suits your needs than a dynamic `aria-label`.

After you've spent time thinking thoroughly about your `aria-label`s and visual labels, make the updates and **test them with your users**. It's hard for us to know if something is usable if it doesn't intersect with our own needs. The only experiences we can truly be experts of are our own. Don't miss the step where you get your information from the source of truth: your users with expertise in their lived experiences.

## Related resources

- [Designing and coding for voice](https://www.briandeconinck.com/designing-coding-voice/)


Users suffer when the accessible name of an element doesn’t match its visual label.

Don’t Overwrite Visual Labels With `aria-label`

Despite being answered time and time again, the button vs. link question prevails.

Should I Use a Button or a Link?


If you've seen "a11y" floating around the web development space and you're not sure what it means or how to say it, you're absolutely not alone. Don't feel bad! Almost no one knows what it is until someone else tells them. I didn't know for a long time. I even created a tool that relies on the mispronunciation of it!

## What is a11y?

"A11y" is a numeronym or number-based word. It is composed of three parts:

- `"a"` - the first letter of the word "accessibility"
- `"11"` - the number of letters between the first and last letters of the word "accessibility"
- `"y"` - the last letter of the word "accessibility"

Numeronyms are very common in web development! Think of "K8s" (Kubernetes), "i18n" (internationalization), and "o11y" (observability) as a few of examples. Some of them have different pronunciations depending on how the number in the middle is pronounced in combination with the letters before and after it.

The way we pronounce "K8s" is different than the way we pronounce "a11y" because of how the numbers flow with the other letters. We _could_ pronounce "K8s" as "kay-eight-ess", but "keights" (see the word eight in the middle?) is a single syllable and a little easier to say.

## How is a11y pronounced?

So how do we pronounce "a11y"? We say "ay-eleven-why". Pronunciations like "al-ee" or "al-eye" don't quite fit like most other pronunciations of numeronyms because they're not saying the number in the middle at all. This isn't to say that all numeronyms are said the same way, but most that use this format follow this idea.

## Why use a11y instead of accessibility?

Numeronyms are often used when their original word is a lot of characters or difficult to pronounce. [According to Wikipedia](https://en.wikipedia.org/wiki/Numeronym), the first numeronym was created in the 1980s for a software account owner's surname because it was too long for the system to handle. "Accessibility" is 6 syllables whereas its numeronym is 1 less. That's not a huge amount of savings, but the phonetics of "a11y" are easier for many people to verbalize than "accessibility" because the there are less "harsh" syllables in comparison.

Numeronyms are also helpful where brevity is important, such as in tweets because Twitter enforces a character maximum. Since there are less characters to type, it can also be more efficient once you get used to using it. For me personally, it's also easier to remember how to spell!

## Do I have to a11y instead of accessibility?

Nope! If you like using the word "accessibility" more than you like using the "a11y" numeronym, please continue to do so. It's definitely a matter of preference and using one or the other does not make you more or less knowledgeable. If someone tells you otherwise, they are unfairly gatekeeping the topic of web accessibility. What truly matters is that you know what "a11y" means so you're not thrown off when you read it in other people's content.

Remember: everyone has different accessibility needs. Some people use "a11y" because it's more accessible to them. If "accessibility" is more accessible to you, that's totally acceptable!


The "a11y" numeronym, why it's important, and how to pronounce it

What the heck is "web a11y"?


It's been awhile since I've set up a React app for testing with Jest and Enzyme. Since I had to look up more than one of these steps to remind myself how to accomplish this, I decided to write a super quick guide in case it helps anyone else.

## Dec. 8th Correction

Enzyme is not yet compatible with React 17. You should make sure the highest version of React you are using is `16.14.0` if you want to use Enzyme with your tests. [This PR](https://github.com/enzymejs/enzyme/pull/2430) will add an adapter for React 17. _Please do not ask them when it will be done, it will be done when they get it done!_

## Step 1: Create the app with `create-react-app`

This requires having `npx` installed. You can read about it [here](https://www.npmjs.com/package/npx).

```bash
npx create-react-app <app-name>
```

## Step 2: If you use Sass modules, like me, install `node-sass`

At the time of this writing, `node-sass@5.0.0` in incompatible and `node-sass@4.14.1` must be installed instead. There's a Stack Overflow answer about it [here](https://stackoverflow.com/questions/64625050/error-node-sass-version-5-0-0-is-incompatible-with-4-0-0/64626556#64626556).

```bash
yarn add node-sass@4.14.1
```

## Step 3. Install the dev dependencies for Enzyme

The `--dev` option is what saves these under `devDependencies` in your `package.json` file. Why do they need to be under `devDependencies`? Because these kinds of dependences are "Packages that are only needed for local development and testing." You can read a little more on that [here](https://docs.npmjs.com/specifying-dependencies-and-devdependencies-in-a-package-json-file).

```bash
yarn add --dev enzyme enzyme-adapter-react-16
```

## Step 4. Configure Enzyme with an adapter in `setupTests.js`

Enzyme needs to know what adapter you want to use. We tell it in the `setupTests.js` file in the `src` directory of your project. You can get more details about setting up Enzyme [here](https://enzymejs.github.io/enzyme/).

Your `setupTests.js` should only have some comments and one `import` statement right now. Just add these lines right after that `import`:

```jsx
import Enzyme from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';

Enzyme.configure({ adapter: new Adapter() });
```

## Step 5. Get to testing! 💪

Everything you need is installed and now you just need to write up some tests. Here are some Jest and Enzyme docs to help you get started:

- [Jest "Getting Started" Guide](https://jestjs.io/docs/en/getting-started)
- [Jest "Testing React Apps" Guide](https://jestjs.io/docs/en/tutorial-react)
- [Enzyme's "Using enzyme with Jest" Guide](https://enzymejs.github.io/enzyme/docs/guides/jest.html)
- [Enzyme API Reference](https://enzymejs.github.io/enzyme/docs/api/)


Learn how to set up and configure a React app for Jest and Enzyme testing in just a few steps.

Set up a React App for Testing with Jest and Enzyme


Scroll-to-top buttons are great for pages that are long enough to require a few scrolls to read everything. They're even better for extremely long pages. Scrolling is a lot of work for some users, especially on a mobile device. We (website creators) can greatly reduce the amount of work it takes to scroll our pages with surprisingly little effort on our part.

One example is the [WAI-ARIA Authoring Practices](https://www.w3.org/TR/wai-aria-practices-1.1), which is 140,923 pixels tall at the time of this writing. I'm not calling them out, it's just one of my favorite pages on the entire internet! [It's a great resource for making accessible custom components](https://ashleemboyer.com/my-favorite-resource-for-making-accessible-custom-components).

Making a scroll-to-top button and making it scroll smoothly is probably a lot easier than you think. It's definitely a lot easier than _I_ thought! The code bits I'm about to show are for React and SCSS, but you don't need to know either. The basic concepts here are for JavaScript and CSS. We'll also cover how to get rid of the smooth scrolling when it's an accessibility concern.The best part of this approach? It requires no focus management! <span aria-hidden>🎉</span>

## Prerequisites

If you don't already have one, you need to add a Skip Navigation Link to your site. It's a quick, easy win as well, and the instructions below reference the one I use on my site. Not sure how to do it? Then read my post on [How I Added a Skip Navigation Link to My Next.js Site](/blog/how-i-added-a-skip-navigation-link-to-my-next-js-site)!

## The React Code

As you may have read in [my post about Skip Navigation Links](/blog/how-i-added-a-skip-navigation-link-to-my-next-js-site#what-does-the-code-look-like), I use Next.js Per-Page Layouts to help me render repeated content, such as navigation links, on many pages. The layout I use for the navigation header is where I placed a Skip Navigation Link and Scroll-to-Top link. The code looks something like this:

```tsx
import styles from './base-layout.module.css';

const BaseLayout = ({ children }) => {
  return (
    <div>
      <a href="#main-content" id="skip-navigation-link">
        Skip Navigation
      </a>
      <SiteHeader />
      <main id="main-content" tabIndex={-1}>
        {children}
      </main>
      <a href="#skip-navigation-link">Back to Top</a>
      <SiteFooter />
    </div>
  );
};
```

What's important from this code:

1. The Scroll-to-Top link goes to the first focusable control on the page, which should be a Skip Navigation Link.
2. The `href` of the Scroll-top-Top link matches the `id` of the Skip Navigation Link.

## The SCSS Code

The code below takes an accessibility- and browser-support- first approach. Rather than making the default behavior for scrolling be smooth, an animation which can be physically harmful to some folks (including myself), it only applies smooth scrolling when two conditions are true:

1. The `prefers-reduced-motion` query is supported ([see the CanIUse.com page](https://caniuse.com/mdn-css_at-rules_media_prefers-reduced-motion))
2. The value of the setting is `no-preference` (which unfortunately is the default value)

```scss
html {
  @media (prefers-reduced-motion: no-preference) {
    scroll-behavior: smooth;
  }
}
```

One thing to keep in mind is that [`scroll-behavior` does not have full browser support](https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-behavior#browser_compatibility). At the time of writing, the feature is still in development for Safari.

## Conclusion

That's it! It really is just a few lines of code. After you add this, everyone will be able to quickly scroll to the top of your website. You've also made it so your site doesn't accidentally harm someone who can't tolerate animations! Well done. I am proud of you!


Adding a scroll-to-top button with smooth scrolling is as easy as adding a few lines of code.

Accessible, Smooth Scroll-to-top Buttons with Little Code


Accessibility can be pretty overwhelming at first. There are a lot of things to consider and it's really hard to figure out what you don't know when you're just starting out. I hope you find this short list useful to help your first dive into making accessible digital content. My focus is usually on websites, but a lot of this is good for things like mobile apps, ebooks, and slideshows, too!

## 1. Color Contrast

Ensuring you have a good contrast between text color and background color ensures nearly everyone can consume your content. People with vision disabilities (vision loss or color blindness) need high contrasting colors. Your minimum goal here is to meet contrast standards for normal and large sized text.

My favorite tool for this is the [WebAIM Contrast Checker](https://webaim.org/resources/contrastchecker/). You can input your foreground and background text colors and it will tell you how they fare under the WCAG level AA and level AAA standards.

![A screenshot of the WebAIM Contrast Checker in action. It shows the overall contrast ratio of two colors to the right of two inputs, and below that it shows whether the contrast passes level AA and AAA standards for both normal and large sized texts.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/headers%2F2020%2F07%2F26-three-thigns%2FScreen%20Shot%202020-07-26%20at%209.53.28%20PM.png?alt=media&token=aa6423ce-f0b1-4b2d-b43d-bb23765d0c40)

## 2. Alternative Text

Alternative text is also important for people with vision disabilities. There are two ways you can go about alternative text depending on your platform.

When you're making a website by writing your own HTML, writing blog posts, or posting to social media sites like Twitter, you can add alt text to images. In HTML, make sure you're providing an `alt` attribute all `img` elements. When writing blog posts, a lot of blogging platforms will have a text input for you to provide alternative text. On Twitter, you can add alternative text as you're about to tweet an image or GIF.

The previous points are only going to be useful for people using a screen reader. These devices pick up those attributes to present images to the person consuming them. However, not all users with vision disabilities use screen readers. So, if you feel like you'd rather make your alternative text available for everyone, it's common practice to surround an image description in square brackets and preface it with "Image description", like this:

```
[Image description: ...]
```

As for actually writing the image descriptions, that's going to take some practice. Imagine you are sitting socially distanced from a friend and you want to show them a picture you've come across on your phone, but you'd have to break social distance to physically show them. How would you describe the image to them in one or two sentences?

## 3. Semantic HTML

This point is a little more technical, but also useful for folks that use blogging platforms that provide text editors. The main lesson for this section? Use the elements that we have been given for their intended uses.

- Need to display things in a list format? Use a bullet (`<ul>` element) or numbered list (`<ol>` element).
- Have a navigation menu at the top of your site? Use a `<nav>` element.
- Have an element that users can click on to perform an important action? PLEASE use a `<button>` element. 😁

Using semantic HTML elments is so important because they're already able to be presented by assistive devices without much addition. You're going to start adding ARIA roles and properties the minute you start using `<div>`s for `<button>`s, and if you don't know what you're doing there, you can severely and negatively impact a screen reader user's experience.

You can read and practice with HTML semantic elements [here](https://www.w3schools.com/html/html5_semantic_elements.asp), on W3Schools.


You'll leave this post with straightforward action items for making your digital content more accessible.

Three Starting Points for Making Accessible Digital Content


We've reached the third part of our React & Firebase series. In [part one](https://ashleemboyer.com/react-firebase-blog-01), we learned how to set everything up. [Last time](https://ashleemboyer.com/react-firebase-blog-02), we made a page for creating new blog posts. Today, we're going to read single posts from our Firebase Realtime Database and show them in our app.

If you haven't read the first two posts, I have some starter code you can use instead. Just make sure you follow steps 1, 2, & 5 from [the first part](https://ashleemboyer.com/react-firebase-blog-01) before you go any further.

## 1. Clone the (Part 3) Starter Code [Optional]

Skip this step if you've successfully completed Part 2. Otherwise, you can clone the code by running the following command in the terminal:

```
git clone https://github.com/ashleemboyer/react-firebase-blog-starter-part-3.git
```

You'll need to change one file before continuing: `src/firebase.js`. If you open it, you'll see the following `config` constant:

```
const config = {
  apiKey: "<YOUR-API-KEY>",
  authDomain: "<YOUR-AUTH-DOMAIN>",
  databaseURL: "<YOUR-DATABASE-URL>",
  projectId: "<YOUR-PROJECT-ID>",
  storageBucket: "<YOUR-STORAGE-BUCKET>",
  messagingSenderId: "<YOUR-MESSAGE-SENDER-ID>",
  appId: "<YOUR-APP-ID>"
};
```

The attributes within the constant are used to connect your app to your Firebase project. To find these values, go to your project settings using through the gear icon in the left sidebar of the [Firebase console](https://console.firebase.google.com). Scroll down to the "Firebase SDK snippet" under "Your apps" and copy the attributes from what they're calling `firebaseConfig`. Replace the attributes in your `config` constant with these values.

Now you can run `npm install` and then `npm run start` to see your project in a browser.

## 2. Inspect the `Post` Component

You can find this component in the `src/pages/post.js` file. Let's take a look at what it does right now.

First, it grabs the slug from the URL using the `Router` we have set up in `src/App.js`. Components passed in to `Route` components within a `Router` have a `match` prop sent to them. There are other ways this prop is sent to components, and you can read more about that [over here](https://reacttraining.com/react-router/web/api/match).

Next, we have a `postSlugs` constant which is an array of slugs that exist with a real blog post. If you look at the database, these match the slugs we've given to the first and second blog posts. The problem is that this code isn't dynamic and it's also not connected to the database. We'll come back to this in a few.

Next, we're checking if the `slug` in the URL bar is one of the `postSlugs`. If it isn't, then the user is trying to see a post that doesn't actually exist. So, we return a `Redirect` to our `404` component. You can read more about the `Redirect` [over here](https://reacttraining.com/react-router/web/api/Redirect).

Finally, we have our return statement. Right now, it returns the same thing for every valid post `slug`. Instead, we want to show the real blog post content that we have stored in Firebase.

## 3. Connect the `Post` Component to Firebase

First, let's add import our `getFirebase` function so we can try to read from the database. While we're at it, we should also import `useState` to help manage a couple of things.

```
import React, { useState } from "react";

import { getFirebase } from "../firebase";
```

Next, let's think about how what we want to manage with `useState`. The first thing that comes to mind is a `loading` state. This will be a boolean that describes whether or not we are trying to load something from the database. We also want a variable for our `currentPost` that we're trying to read from the database. Replace the `postSlugs` line with the following two lines of code:

```
const [loading, setLoading] = useState(true);
const [currentPost, setCurrentPost] = useState();
```

We want to start in a loading state so the page can show something different to indicate to a user that the page is loading. You can show an animation, GIF, plain text, whatever you please. We'll keep it simple for now and just return some text like this:

```
if (loading) {
  return <h1>Loading...</h1>;
}
```

Our database call needs to go right before this `if` statement, however. If we place it after, it will never be reached because the `if` statement is making the code return early. Here's what we'll add after our calls to `useState` and before the `if` statement we just wrote:

```
if (loading && !currentPost) {
  getFirebase()
    .database()
    .ref()
    .child(`/posts/${slug}`)
    .once("value")
    .then(snapshot => {
      if (snapshot.val()) {
        setCurrentPost(snapshot.val());
      }
      setLoading(false);
    });
}
```

Let's update our check on whether a post exists or not. Update `postDoesNotExist` to the following:

```
const postDoesNotExist = !currentPost;
```

These conditions might be a little confusing at first. What are we checking for? It might help to list the steps of execution here, which you can play around with yourself by adding some console logs to the file.

1. On first load: `loading` is true and `setCurrentPost` is undefined, so we go inside of the `if` statement. Once we make it into the `then`, if `snapshot.val()` returns an object (it'll be null if no post exists with the given `slug`), we call `setCurrentPost`, making `currentPost` no longer undefined.
2. After `setCurrentPost` call: Making this call will re-render the component. We reach our `if (loading && !currentPost)` statement again. Since `currentPost` is now defined, we do not go in the code block again, thus keep ourselves from unnecessarily making calls to the database. We reach the `if (loading)` statement. `loading` is still true, so the component returns some text and doesn't do anything else.
3. After `setLoading` call: Making this call will re-render the component. `loading` is now false and `currentPost` might be undefined or an object. That's where the `if (postDoesNotExist)` check comes in. If we didn't get a post back from the database, we return a `Redirect`, like before. Otherwise, we continue on to our final `return` where we show the post.

_I hope these steps aren't overwhelming and they help you see the power of hooks and state management! They're some of the coolest things about React, to me._

Here's how I'm displaying posts:

```
return (
  <>
    <img src={currentPost.coverImage} alt={currentPost.coverImageAlt}>
    <h1>{currentPost.title}</h1>
    <em>{currentPost.datePretty}</em>
    <p dangerouslySetInnerHTML={{ __html: currentPost.content }}></p>
  </img>
);
```

I also added a `12px` margin to the top of `<p>` elements in `src/index.js`.

Now, when you click a "Continue reading..." link or manually navigate to one of your posts, you should see something like this:

![Screenshot of a single blog post's page.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-03%2Fpost.png?alt=media&token=4a9abd6a-9549-467f-a473-ff86ae47357a)

Please [send me an email](mailto:hello@ashleemboyer.com) or [a Twitter DM](https://twitter.com/ashleemboyer) if you have any questions or concerns. I love hearing from you! 😊


Learn how to build a blog site with React and Firebase.

Build a React & Firebase Blog Site

Build a React & Firebase Blog Site Part 3


Welcome back! This is the second in a series of posts that will teach you how to build a blog site using React and Firebase. If you haven't read [the first post in the series](https://ashleemboyer.com/react-firebase-blog-01), I encourage you to do so. I'm including starter code for this post, but you'll additionally need to go through the following steps from the previous post to use it:

- Step 1: Sign up for Firebase (if you don't have an account already)
- Step 2: Create a project
- Step 5: Add Data to the Database

A fair warning: since this post is building off of Part 1, it assumes you have read the post if you're closely following along.

## 1. Clone the (Part 2) Starter Code [Optional]

Skip this step if you've successfully completed Part 1. Otherwise, you can start clone the code by running the following command in a terminal:

```
git clone https://github.com/ashleemboyer/react-firebase-blog-starter-part-2.git
```

You'll need to change one file before continuing: `src/firebase.js`. If you open it, you'll see the following `config` constant:

```
const config = {
  apiKey: "<YOUR-API-KEY>",
  authDomain: "<YOUR-AUTH-DOMAIN>",
  databaseURL: "<YOUR-DATABASE-URL>",
  projectId: "<YOUR-PROJECT-ID>",
  storageBucket: "<YOUR-STORAGE-BUCKET>",
  messagingSenderId: "<YOUR-MESSAGE-SENDER-ID>",
  appId: "<YOUR-APP-ID>"
};
```

The attributes within the constant are used to connect your app to your Firebase project. To find these values, go to your project settings using through the gear icon in the left sidebar of the [Firebase console](https://console.firebase.google.com). Scroll down to the "Firebase SDK snippet" under "Your apps" and copy the attributes from what they're calling `firebaseConfig`. Replace the attributes in your `config` constant with these values.

Now you can run `npm install` and then `npm run start` to see your project in a browser.

## 2. Add a Page for Creating Posts

To get started on implementing a "Create Post" feature, let's first make a page we'll use to create posts. Add a `create.js` file in `src/pages`. We're going to keep it really simple for now to make sure everything is still working.

> Developing code is most easy when you take incremental steps and check your work along the way.

Our `Create` component will give a friendly, "Hello," for now.

```
import React from "react";

const Create = () => {
  return <h1>Hello, from Create!</h1>;
};

export default Create;
```

Try navigating to the `/create` page. Uh, oh... the page isn't found?

![The 404 page.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-02%2F404.png?alt=media&token=4665d673-fc43-4f64-ab14-4d5b8bf7ec9e)

No worries! We just need to add a `Route` for our new page in `src/App.js`. First add an import for the `Create` component:

```
import Create from "./pages/create";
```

Then, add the following `Route` below the one for the `/` path:

```
<Route path="/create" component={Create} />
```

The new create page should be working now!

![The create page.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-02%2Fcreate-hello.png?alt=media&token=a4a5a0ac-005e-448c-8493-450a60f1f5e6)

## 3. Make Inputs for Describing Posts

Now, let's think about the data structure we have in our Realtime Database. Each of the following are attributes we use to describe a blog post:

- title
- slug
- date
- coverImage
- coverImageAlt
- content

Consider these two questions: Which of these attributes do we need to create an `<input>` for? Which ones can we automatically generate with some additional code? Well, ...

If I were making this blog site for a client, I would auto-generate the `slug` and the `date`. Dates aren't that hard to auto-generate, but slugs can be because of punctionation. We're not going to handle that here, but feel free to give it a try on your own! In addition, I'd likely provide a file upload input for `coverImage`, but that's also a little more complex than I'd like to take this post.

So, `date` is the only thing we're going to auto-generate. We'll have inputs for everything except `content`, which will get a `<textarea>`. Let's add all of those to our component and handle their values with `useState`. Your `src/pages/create.js` file should look like this:

_If this seems like a lot of redundant code to you, good catch! (And I'm sorry. 😅) We'll fix that in a "going further" post._

```
import React, { useState } from "react";

const labelStyles = {
  display: "block",
  marginBottom: 4
};

const inputStyles = {
  width: "100%",
  height: "2rem",
  lineHeight: "2rem",
  verticalAlign: "middle",
  fontSize: "1rem",
  marginBottom: "1.5rem",
  padding: "0 0.25rem"
};

const Create = () => {
  const [title, setTitle] = useState("");
  const [slug, setSlug] = useState("");
  const [coverImage, setCoverImage] = useState("");
  const [coverImageAlt, setCoverImageAlt] = useState("");
  const [content, setContent] = useState("");

  const createPost = () => {
    console.log({ title, slug, coverImage, coverImageAlt, content });
  };

  return (
    <>
      <h1>Create a new post</h1>
      <section style={{ margin: "2rem 0" }}>
        <label style={labelStyles} htmlFor="title-field">
          Title
        </label>
        <input
          style={inputStyles}
          id="title-field"
          type="text"
          value={title}
          onChange={({ target: { value } }) => {
            setTitle(value);
          }}
        />

        <label style={labelStyles} htmlFor="slug-field">
          Slug
        </label>
        <input
          style={inputStyles}
          id="slug-field"
          type="text"
          value={slug}
          onChange={({ target: { value } }) => {
            setSlug(value);
          }}
        />

        <label style={labelStyles} htmlFor="cover-image-field">
          Cover image
        </label>
        <input
          style={inputStyles}
          id="cover-image-field"
          type="text"
          value={coverImage}
          onChange={({ target: { value } }) => {
            setCoverImage(value);
          }}
        />

        <label style={labelStyles} htmlFor="cover-image-alt-field">
          Cover image alt
        </label>
        <input
          style={inputStyles}
          id="cover-image-alt-field"
          type="text"
          value={coverImageAlt}
          onChange={({ target: { value } }) => {
            setCoverImageAlt(value);
          }}
        />

        <label style={labelStyles} htmlFor="content-field">
          Content
        </label>
        <textarea
          style={{ ...inputStyles, height: 200, verticalAlign: "top" }}
          id="content"
          type="text"
          value={content}
          onChange={({ target: { value } }) => {
            setContent(value);
          }}
        />
        <div style={{ textAlign: "right" }}>
          <button
            style={{
              border: "none",
              color: "#fff",
              backgroundColor: "#039be5",
              borderRadius: "4px",
              padding: "8px 12px",
              fontSize: "0.9rem"
            }}
            onClick={createPost}
          >
            Create
          </button>
        </div>
      </section>
    </>
  );
};

export default Create;
```

Here's what your page should look like now:

![The create page with inputs.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-02%2Fcreate-screen.png?alt=media&token=24abdd3c-da90-4438-a488-7c6fb95112d1)

Briefly fill in all of these fields and see what happens when you click the "Create" button! Is your console open? Then you should see an object printed with the values of all your inputs. Here's what mine looks like (_click to expand_):

![The create page with filled inputs and their values logged to the console.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-02%2Fcreate-values-logged.png?alt=media&token=2de7263e-f573-4a4c-85a4-050ab479fee1)

## 4. Write a Create Function

Neat! This is also what I mean by incremental changes to code. Take it step by step. Let's get to the exciting part! We're going to send some stuff back to the database. First, we need to import our `getFirebase` function from `src/firebase.js`.

```
import { getFirebase } from "../firebase";
```

Now, add the `generateDate()` function, update the `createPost` function, and destructure the `history` prop from the `Create` component params:

```
const generateDate = () => {
  const now = new Date();
  const options = { month: "long", day: "numeric", year: "numeric" };

  const year = now.getFullYear();

  let month = now.getMonth() + 1;
  if (month < 10) {
    month = `0${month}`; // prepend with a 0
  }

  const day = now.getDate();
  if (day < 10) {
    day = `0${day}`; // prepend with a 0
  }

  return {
    formatted: `${year}-${month}-${day}`,             // used for sorting
    pretty: now.toLocaleDateString("en-US", options)  // used for displaying
  };
};
```

```
const createPost = () => {
  const date = generateDate();
  const newPost = {
    title,
    dateFormatted: date.formatted,
    datePretty: date.pretty,
    slug,
    coverImage,
    coverImageAlt,
    content
  };
  getFirebase()
    .database()
    .ref()
    .child(`posts/${slug}`)
    .set(newPost)
    .then(() => history.push(`/`));
};
```

```
const Create = ({ history }) => {
  ...
}
```

Fill in your inputs like we did a few minutes ago, click "Create post", and you should be brought to the home page with your new post at the very top!

![The home page with the new post listed first.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-02%2Fnew-post.png?alt=media&token=85aa1f65-6be1-430f-badc-9490b5e6c66d)

## 5. Wrapping Up

Whew! I thought we'd be able to talk about all 4 CRUD functions in one post, but that was a lot. We'll continue on this adventure tomorrow. Great job so far. 💪

If come across any issues or questions, [send me an email](mailto:hello@ashleemboyer.com) or [DM me on Twitter](https://twitter.com/ashleemboyer)! Catch you again tomorrow. 😊


Build a React & Firebase Blog Site Part 2


Welcome! This is the first in a series of posts that will teach you how to build a blog site using React and Firebase. This one will probably be the longest because there are few things to do to set everything up.

At the end of this post, you'll have learned how to connect your app to Firebase and pull some data from [Firebase's Realtime Database](https://firebase.google.com/docs/database). Next time, we'll start setting up our CRUD functions with a "Create Post" feature. After that, we'll see what we can do to make an interface on the frontend that will make it easy to call our CRUD functions and easy to create more interesting functions.

Ready to get started? :)

## 1. Sign up for Firebase

This one is easy! Head over to [Firebase's website](https://firebase.google.com/) and click the "Get started" button. The page looks like this:

![Firebase's home page with a "Get started" button.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Ffirebase-home.png?alt=media&token=44402b1f-339f-4343-817d-952bc6c3bbe4)

You'll be prompted to choose a Google account if you're not already signed in to one. Once you're signed in, you can create a project. Here's what that page will look like if you're brand-new to Firebase:

![The Firebase console where a project can be created.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Ffirebase-welcome.png?alt=media&token=8433b1fc-49ff-42a3-8bb1-21e52cb966be)

## 2. Create a Project

Click the "Create a project" button to begin the three step process. First, you'll be prompted for a project name. I'm naming my project `react-firebase-blog`. You can change your project ID if you want, but going with the automatically generated one is fine too.

![Step 1 of the process.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Fcreate-project-01.png?alt=media&token=c238d4b6-3580-4f3d-9a92-4651cd01662d)

Step 2 asks us if we want to set up Google Analytics for the project. I'm selecting "Not right now". If you choose this option, the process ends here. Otherwise, there's another step

![Step 2 of the process.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Fcreate-project-02.png?alt=media&token=fb748ae2-44fb-4626-ada7-f2b31e73a510)

Click "Create project" and you'll be brought to a loading screen. When it says, "Your new project is ready," click the "Continue" button.

![The "Your project is ready" message with a "Continue" button.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Fcreate-project-ready.png?alt=media&token=3f419470-28e2-4a07-8b36-92b32f8a5b3a)

## 3. Clone the Starter Code

You can clone the starter code by running the following command in a terminal:

```
git clone https://github.com/ashleemboyer/react-firebase-blog-starter.git
```

Let's see what we've got! Go ahead and get the project rolling by changing into the `react-firebase-blog-starter` directory, running `npm install`, and finally running `npm run start`. Here's what you should see:

![Preview of the starter app.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Fstarter-site.png?alt=media&token=a0e21d1e-a951-4871-a98f-a9c42f588697)

Hooray! Go ahead and explore the project a little. I'll highlight a few areas for you to begin.

1. `src/App.js`

   We have 4 `Routes`: the home page, a 404, and another for handling blog post slugs (aka URLs). You might be wondering why there's not one for handling non-matching paths. Good catch! We're actually handling that in the `Post` component (`src/pages/post.js`). Let's go ahead and look at that one.

2. `src/pages/post.js`

   Because we're using a Router in `src/App.js` (comes from `react-router-dom`), the components we name in `Route` elements will have a [`match`](https://reacttraining.com/react-router/web/api/match) passed into their props. We can get the slug for a post from the URL bar with `match.params.slug`, then compare that to a list of slugs we support on the site. Those are hard-coded into a `postSlugs` variable for now. If the slug does not exist, we return a `Redirect` to our 404 page. Otherwise, we'll display the correct post.

3. `src/pages/home.js`

   First, you'll se the `blogPosts` variable. We're hard-coding our posts until we connect our app to Firebase. All this page does is return a `section` element for every blog post in the `blogPosts` array. You shouldn't need to change anything after the `return` statement as we make our way through this series.

## 4. Connect Firebase to the application

First, install the [`firebase` package](https://www.npmjs.com/package/firebase) by running `npm install firebase` in the root directory of the project.

Now, create a JavaScript file in the `src` directory of the project and call it `firebase.js`. This is where we'll define our Firebase configs and initialize the Firebase objects.

Before we add some code to this file, let's get the config data we need about our Firebase project. Go to the Firebase project settings by clicking the settings gear in the left sidebar and selecting "Project settings" from the menu. Scroll down to the "Your apps" section of the page. It's probably at the bottom. It should say, "There are no apps in your project."

![Screenshot of the 'Your apps' section of the project settings.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Fproject-settings.png?alt=media&token=63cb601f-0eb7-49eb-a7c9-dbb5f6bf53ac)

Click the circle that looks like `</>` in order to add Firebase to a web app. You'll be prompted for the App's nickname. I'm calling mine `React Firebase Blog`.

![Screenshot of the prompt for the app's nickname.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Fapp-nickname.png?alt=media&token=513f98b4-37ef-42aa-b45f-f793e5e37c6c)

Click the "Register app" button, and after the page finishes loading, you'll see some HTML code that has a variable called `firebaseConfig`. Copy the JSON attributes from that variable and hold on to them for our `firebase.json` file. Click the "Continue to console" button to get back to your project settings. If you lose the JSON attributes you copied previously, you can find them again here, under the "Your apps" section that now has our app listed.

Let's go back to our `firebase.js`. Have your config data ready and plug it in to the following code:

```
import firebase from "firebase/app";
import database from "firebase/database";

const config = {
  apiKey: "<YOUR-API-KEY>",
  authDomain: "<YOUR-AUTH-DOMAIN>",
  databaseURL: "<YOUR-DATABASE-URL>",
  projectId: "<YOUR-PROJECT-ID>",
  storageBucket: "<YOUR-STORAGE-BUCKET>",
  messagingSenderId: "<YOUR-MESSAGE-SENDER-ID>",
  appId: "<YOUR-APP-ID>",
};

let firebaseCache;

export const getFirebase = () => {
  if (firebaseCache) {
    return firebaseCache;
  }

  firebase.initializeApp(config);
  firebaseCache = firebase;
  return firebase;
};
```

The `getFirebase()` function will ensure we only call `initializeApp` one time.

## 5. Add Data to the Database

We can't read any data from our database until we actually add to it! Go back to your Firebase project and click the "Database" option under the "Develop" heading in the sidebar. You'll have to scroll down the page a little until you find the "Realtime Database" section.

![Screenshot of the Realtime Database section.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Frealtime-database.png?alt=media&token=2bc78aa3-e902-46fd-a775-95042cd5cc0e)

Click the "Create database" button within this section. You'll see a modal come up asking you about the security rules for your database.

![The 'security rules' modal.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Fsecurity-rules.png?alt=media&token=fbd9e6fc-63ac-41d3-b8c9-779a9224c598)

Select "Start in **test mode**" and click the "Enable" button. Your database will be empty and read something like:

```
<YOUR-PROJECT-ID>: null
```

If you didn't already know, the Realtime Database is just a JSON object. You can read more about that [here](https://firebase.google.com/docs/database).

The quickest way to get started is to import data using a JSON file. I'm also providing this for you in case you're following along closely and want to have the same things show as what I have here. You can find this file in the root directory of the starter project. Click the three dots menu and select "Import JSON" to get to the file upload. Browse for your file, and then click the "Import" button.

Now you should have some data attributes you can expand and explore!

![The data imported into the Realtime Database.](https://firebasestorage.googleapis.com/v0/b/ashleemboyer-2018.appspot.com/o/images%2Freact-firebase-blog%2Fpart-01%2Fdata.png?alt=media&token=70461f67-df46-41b4-b15a-c53fc343d3b4)

## 6. Read from the Database

Finally! The moment we've all been waiting for. Let's head over to `src/home.js` and see if we can get some stuff from the database!

First, add some imports to the top of the file:

```
// You only need to add the `{ useState }` portion here.
import React, { useState } from "react";

// This is new.
import { getFirebase } from "../firebase";
```

Now, let's get `blogPosts` into a state and try to read them from the database. You can read more about the `useState` hook over [here](https://reactjs.org/docs/hooks-state.html). We're also going to add a `loading` state so we can easily do two things:

1. Make sure we only call `getFirebase` once
2. Show the user a loading screen while we wait for data

Replace the `blogPosts` constant with the following code:

```
const [loading, setLoading] = useState(true);
const [blogPosts, setBlogPosts] = useState([]);

if (loading && !blogPosts.length) {
  getFirebase()
    .database()
    .ref("/posts")
    .orderByChild("dateFormatted")
    .once("value")
    .then(snapshot => {
      let posts = [];
      const snapshotVal = snapshot.val();
      for (let slug in snapshotVal) {
        posts.push(snapshotVal[slug]);
      }

      const newestFirst = posts.reverse();
      setBlogPosts(newestFirst);
      setLoading(false);
    });
}

if (loading) {
  return <h1>Loading...</h1>;
}
```

Tada! You should see the exact same thing we had before. 🎉

## 7. Wrapping Up

There was a ton of stuff here. If you have any questions or concerned, please [send me an email](mailto:hello@ashleemboyer.com) or [DM me on Twitter](https://twitter.com/ashleemboyer)! I'll try to give you a hand if you're feeling stuck or overwhelmed. Stay tuned for tomorrow's post where we will cover writing CRUD functions for our new, fancy blog site! If you're feeling squirrely and want to give it a go before then, I encourage you to check out the [Firebase documentation](https://firebase.google.com/docs/database/web/start).


Build a React & Firebase Blog Site Part 1&mdash;Setup and Read Data


I came across some issues on touch screens where I have a navigation menu expanded and the common "shadow" showing on the non-menu portion of the screen. When I tried tapping on the "shadow" to close the menu, way too many things were happening! Here's a quick illustration of what sort of screen I'm talking about:

![Mobile screenshot of a menu and its shadow](https://thepracticaldev.s3.amazonaws.com/i/ql9hc8t6rgeghdx1ikgw.png)

When a user taps on the "shadow" portion of the screen, they expect the menu to close. Nothing else should happen. You can handle this by adding a `touchstart` event listener to the element used for the shadow, but there are a couple of things to watch out for. It won't behave the same as a `click` event listener you use for the desktop version of your app.

It's all about when events are fired. A `click` event doesn't go until after a click is over and a mouse button is released. So, when a user clicks on the "shadow" with their mouse, there aren't any side effects. It's a different story for touchscreens, however.

If the items "behind" the "shadow" are clickable, a user touching the "shadow" to close the menu will also cause fire off the click events on those items. It's a pretty simple fix. In your `touchstart` listener, all you have to do is call `preventDefault` on the event passed into the listener. It might go something like this:

![Screenshot of touchstart event listener code showing call to preventDefault and some example lines of code for hiding the shadow and menu](https://thepracticaldev.s3.amazonaws.com/i/llil1vy7msaoswf3dbtf.png)

It's really that easy&mdash;a one-line fix. It wasn't super obvious to me at first, so I hope this helps clear things up for anyone else in the same boat as me. Have you ever run into similar issues? If so, enlighten us in the comments and save us some pain! :)


The touchstart event in mobile web apps is a little different than the click event. Here's how I solved an issue I've run into frequently.

How to Handle touchstart Events with Stacked Elements


As someone who's new to the web dev game, I find it hard to accept all my ideas as good ones. Yes, you read that right, _all_ ideas are good ideas. Ideas are similar to questions, it's all about the timing. Every single idea you have leads to a learning experience.

{% link ashleemboyer/don-t-be-afraid-to-ask-questions-5g99 %}

There's a lot of pressure to make something _cool_ or _super useful_ and _profitable_. You don't have to do that right now, especially if you're learning a new framework. You can make any app you want to, for whatever reason you want to. If no one is getting hurt, just do it!

There are no dumb ideas. Some ideas are better than others obviously, but all ideas keep our creative juices flowing. Once you get started, it'll be hard to stop. Eventually, you'll find the best idea to suit your current situation. All you have to do is sit and listen to your thoughts without judgment. Let them all pour out freely.

Now, let's hear those app ideas! Maybe you'll find someone with a similar idea. Maybe get in touch and think about collabing. :)


Like questions, there are no dumb ideas. Every single idea you have leads to a learning experience.

Just Make That App


I decided to take this approach when I made [https://blackbirthdays.com](https://blackbirthdays.com). Originally, for the month of February, it showed a different person each day for their birthday. So, since there was very static data for the site, I decided to just feed the information into it with a JSON file. I wanted to practice something with Gatsby, so I got to practice [programmatically creating pages from data](https://www.gatsbyjs.org/tutorial/part-seven/) and [using GraphQL for getting data](https://www.gatsbyjs.org/tutorial/part-four/).

I couldn't remember exactly every step for doing this, so [I made a new site](https://ashleemboyer.github.io/colors/) for this post specifically. No worries, I plan on making it way better soon. I hope it can become a helpful tool for looking at text color/background color contrasts eventually. Anyways, here we go!

### 1. Create your project

The easiest step. :) Head over to the [Gatsby tutorials](https://www.gatsbyjs.org/docs/quick-start/) if you have any issues or need help setting things up.

![Terminal commands for setting up a new Gatsby project](https://thepracticaldev.s3.amazonaws.com/i/d89dd76oml8yy3rsepy6.png)

### 2. Create the JSON file

Put a new JSON file in the root directory of your project. I had a little bit of issue with the data structure itself, but I think it just takes practice. It's easier to read data from GraphQL with arrays, so try to put your data into that sort of format.

![How I formatted the color data](https://thepracticaldev.s3.amazonaws.com/i/peuhc2g8ovcrkvoajzj5.png)

### 3. Create a template file

This template file defines how all of your dynamically created pages will be displayed. Cool, huh??! You can read a bit more about this [on Gatsby's site](https://www.gatsbyjs.org/blog/2019-05-02-how-to-build-a-blog-with-wordpress-and-gatsby-part-3/#creating-a-page-template).

![Code for the template file](https://thepracticaldev.s3.amazonaws.com/i/6jbcscj813zgm4ekuyeb.png)

### 4. Make the `gatsby-node.js` file create all the pages

This file should already be in your root directory from the `gatsby new` command from step 1. This is where you implement the `createPages` API function and tell the site about the template file you created in the previous step. On the second line of the screenshot below, I specify the JSON file from step 2.

![Code for the gatsby-node.js file](https://thepracticaldev.s3.amazonaws.com/i/x42s5fslzctbnfrpurs0.png)

### 5. Restart the development server and preview your site

Everything should be good to go at this point and you can start styling. Have at it! Share your results if you give this a try, or let me know if something seems off in any of the steps. Enjoy! :)


Looking for the next thing to try after generating your site with markdown? Try it out with a static JSON file.

Build a Multi-Page Gatsby Site from JSON


The worst part of finishing a tutorial is not knowing what to do next. You _could_ go look up some app ideas online, but aren't you tired of making to-do lists and calculators you probably won't use? It probably feels like there's nothing left to make.

![Jack Tripper saying, "Well, as a matter of fact, there is something"](https://media.giphy.com/media/FeiQbJ2BjZLoHdD5oB/giphy.gif)

What about a resume? I spent today coding mine up using Gatsby (I really needed to use the typography and icon plugins), then I did a swift little `ctrl-p` > "Save to PDF". It was much easier for me to do it this way than to make something in LibreOffice Draw. The program always seems to distort colors and such anyways.

So... what makes a resume the _perfect_ project?

- It's only one page&mdash;that's not too much work.
- You can practice laying things out with CSS if you do what I did and use two columns.
- There's all types of elements you can practice with: headers, paragraphs, links, and lists.
- Again, if you use two columns, you can practice placing your elements in the correct order for accessibility.
- You can use get some extra practice with tools like [Lighthouse](https://developers.google.com/web/tools/lighthouse/) that test accessibility, performance, and best practices.
- After it's done, you can add it to your personal/portfolio site(s) and have something great-looking to brag about. 😉

Still feeling a little uninspired about design? Take a look at these sites for some resume examples:

- [Piktochart](https://piktochart.com/blog/well-designed-resume-examples-inspiration/)
- [Dribbble](https://dribbble.com/search?q=resume)
- [Awwwards](https://www.awwwards.com/inspiration/search?text=resume)

If you have any other ideas, or would like to share your work, please do leave it in the comments below or [send me a tweet](https://twitter.com/ashleemboyer)! I love seeing what other people create. 😊


Do you ever feel stumped on what project to create in a new framework after you finish your first tutorial? This one is simple and also a productive use of your time.

Posts Related to the "web-development" Tag