DEV Community: Audrea Cook

A Tale of Two Classes

Audrea Cook — Fri, 17 Jul 2020 17:06:31 +0000

Yesterday, I was challenged by a potential employer (fingers crossed) to share a few JS classes I’m proud of. I had a lot of fun writing this up, and I figured I would share it with y’all, as well.

Below, you will find code samples from my React app, OurCal, which is deployed on Heroku, here. I chose this project because it was originally written in vanilla JS before I refactored it, and I thought it would be interesting to show how the classes evolved.

The vanilla JS Block class creates the 25x25 pixel grid, or block. The constructor accepts the block’s name and an array of pixels. To create the individual Pixel objects, the constructor calls the createPixels method, which loops through the pixels array and calls on the Pixel class for each element. This method returns the newly-created Pixel objects as an array to be sent to the back end.

The vanilla JS Pixel class is a simple constructor. It accepts four arguments, the x and y coordinates, the background color, and the color_variable representing the pen used to select the pixel.

After converting OurCal to a React app, the classes get a bit more complex (and fun).

The React CompleteBlock class displays a fully-colored block. It takes the block’s name and block data as props. The createBlock and createColumns methods work in tandem to populate a grid with individual Pixel objects. On componentDidMount(), the pixels are then filled with the appropriate background colors, using the colorPixels method.

The React Pixel class creates the individual pixels, based on the block’s location, which is passed in through props. If the location is Template (the editable block), a click handler is attached to the pixel. The handleClick method toggles the pixel’s className (and corresponding background color). Pixels in the Template location are also added to the Redux store through componentDidMount.

Bug Alert!

The current Heroku deployment contains a bug dealing with the toggled background colors.

I am aware of it and have addressed the problem in the code. I’m working on deploying the fix, hopefully, later today.

Upgrade Your Flatiron Blog - Part 2

Audrea Cook — Thu, 09 Jul 2020 22:15:00 +0000

A few months ago, I shared how to spruce up your Flatiron blog. Since then, I’ve continued to publish a new blog post each week. Learn.co provides Flatiron students with a built-in blogging platform that is serviceable, if not flashy. Of CodeWitch.dev’s 35 blog posts, I wrote and published 30 of them through Learn.co.

At the beginning of June, a prospective employer asked me what I knew about CMSs, or Content Management Systems. At the time, my answer was, “Honestly? Not much.”

Determined to come up with a better answer for my follow-up email, I did some research. I learned that a CMS is simply a way to handle all the content (pages, blog posts, etc.) for a website. A CMS is especially helpful for team members who aren’t as tech-savvy because it wraps the tricky code into a nice, WYSIWYG (what you see is what you get) format.

As an experiment, I decided to migrate my Flatiron blog to a CMS. Through this process, I figured I would learn a new skill, have a better understanding of what a CMS is actually good for, and maybe – just maybe – find a nicer text editor for my blog.

Choose a CMS

There are countless CMSs out there, but I ultimately settled on Forestry.io for the following reasons:

The free plan would fit my needs perfectly.
It integrates cleanly with GitHub Pages and Jekyll, which is how Flatiron initially builds your blog.
It has a live preview server.
It is git-based, meaning all posts and edits would be pushed to the GitHub repository first, making it easy to track changes.
It came highly recommended.

Sign Up for Forestry.io

If you’re ready to make the change, sign up for your free Forestry.io account. I chose to sign up through GitHub, but you can use a regular email address and password if you like.

Import Your Blog

Once you’ve logged in, importing your blog is simple.

Click the green Add Site button.
Within the popup, select your static site generator. Again, your Flatiron blog is already built with Jekyll.
Select your git provider. Your Flatiron blog is on Github. Make sure the Quick Setup via OAuth toggle is on.
Choose your git repository (it should look like YourUsername/BlogName.github.io) and the branch you would like to use.

From here, Forestry will import your blog!

Start Writing

On the left sidebar, Forestry.io will detect the basic components of your blog. They will be broken into Pages (your home, about, and any other static pages you created) and Posts (your individual blog posts).

If you click the Posts button, it will display all the blog posts you’ve published so far. One feature I really like is the Set as draft option, located under the More Options (...) icon to the right of each post. This way, you can make edits and use the live previewer without changing your published post until you are ready!

To begin a new blog post, click the Create new button. On the left will be your front matter (learn how to configure that here), and the right will display your WYSIWYG editor.

For the most part, this view works perfectly for me. However, I occasionally want to tweak my code blocks or customize the HTML a bit more. For this, I click the More Options (...) icon at the top of the page and select the Raw Editor. This displays your blog post in its bare Markdown format, complete with handy-dandy line numbers!

Make Forestry.io Your Own

By now, you are successfully using a CMS to run your technical blog! The simple instructions I provided are a great start, but Forestry.io has many tools yet to be explored! I highly recommend you check out their awesome docs. I also suggest reading up on Forestry.io’s Front matter and Media tools. In short: have fun with it! It is your blog, after all.

COVIDiary pt. 11 - Basic Header

Audrea Cook — Fri, 26 Jun 2020 21:29:46 +0000

Welcome to Part 11 of the COVIDiary project! If you’re just joining us or missed a post, here’s what we’ve done so far:

This week, we’re creating a simple Header component. We aren’t getting into the nitty-gritty of adding auth just yet. Today’s goal is to get the basic layout of our Header. Before we begin, run yarn start in your terminal to open your application in the browser.

Stub the Component

Create a new file in your src/components folder called Header.js. Add a simple functional component.

import React from 'react';

const Header = () => {
  return (
    <div>
      COVIDiary
    </div>
  );
};

export default Header;

Import the Header

Let’s add our Header to App.js.

In src/App.js:

import Header from './components/Header';

Just after the opening <div> In the render() section, add our component:

<Header />

You can remove all the default React code if you’d like. I moved it into a main tag so I had a placeholder between my header and footer.


<main>
  <img src={logo} className="App-logo" alt="logo" />
  <p>
    Edit <code>src/App.js</code> and save to reload.
  </p>
  <a className="App-link" href="https://reactjs.org" target="_blank" rel="noopener noreferrer">
    Learn React
  </a>
</main>

Right now, your project will look something like this:

Fill in the Details

Let’s start to format our header to match our wireframe sketch. From here on out, we’re working in components/Header.js.

For our header, we will be using React-Bootstrap’s NavBar and Nav components. To begin, import the components at the top of your file:

import Navbar from "react-bootstrap/Navbar";
import Nav from "react-bootstrap/Nav";

Now, let’s replace our div with NavBar. We’ll pass it props to adjust the styling.

<Navbar expand='md' bg='dark' variant='dark' as='header'>
  {/*expand - breakpoint at which hamburger menu expands*/}
  {/*bg - sets background color*/}
  {/*variant - use dark color scheme for dark bg*/}
  {/*as - converts default <div> tag to <header> tag*/}
</Navbar>

Within our Navbar, let’s put our site’s name on the left. You could also use a logo here, if you had one. We’ll have this element link to our root page.

  <Navbar.Brand href="/">COVIDiary</Navbar.Brand>

We also want to make sure our Navbar is responsive so it will adapt when users adjust their screen sizes.

<Navbar.Toggle aria-controls="responsive-navbar-nav"/>

Finally, let’s add the main navigation links. We want them to collapse into a hamburger menu on smaller screens, so we will wrap them in a <Navbar.Collapse> component. Note the id and className come straight from the React-Bootstrap documentation.

<Navbar.Collapse id="responsive-navbar-nav">
  <Nav className="ml-auto" as='nav'>
  {/*ml-auto - aligns nav links to the right of the container*/}
    <Nav.Link href="/about">About</Nav.Link>
    <Nav.Link href="/register">Register</Nav.Link>
  </Nav>
</Navbar.Collapse>

Our basic header is complete! Here it is on medium and larger screens:

Here is the hamburger menu on small screens:

And here is the expanded hamburger menu:

Coming Up

Now that we’ve got our Header component, we’re ready to get into some more complicated aspects of our front end!

Words Matter

Audrea Cook — Fri, 19 Jun 2020 21:43:53 +0000

Earlier this week, GitHub announced they are working on changing their default branch name from master to main to show solidarity with the Black Lives Matter movement. This sparked a bit of a Twitter storm, with arguments both for and against this change.

As a white, cis-gendered woman of middle-class, I haven’t felt like I had much to personally contribute to the Black Lives Matter discussion. Instead, I’ve used my platform to amplify the voices of others – to share with, support, and encourage those who fight for an end to the systemic racism in our country.

But now we’re talking about words. On this, I have something to say (and a degree to back it up).

My Path

I grew up in a small community of mostly-white, mostly-middle-class, country folk. I was taught to never say the N-word, but I heard it every now and again. But other words were deemed perfectly acceptable. I am ashamed to say that “gay” and “retarded,” both used in a derogatory sense, were a regular part of my lexicon. They were just the words everyone used (remember this for later).

When I was in college, my brother, Adam, came out as a proud gay man. Shortly thereafter, my sister-in-law, Kyal, came out as a lesbian. Suddenly, I cared very much when someone described something negatively as “gay.” Two of the most beautiful, hilarious, and kind people in my universe are gay. There isn’t a single negative thing to be said about either of them, and I’ll have words with anyone who would like to say otherwise.

The term “gay,” as I had used it growing up, directly hurt people I cared about. So I stopped using it.

Seven years ago, a princess was born. Her name is Haylie Sophia Grace, she is my niece, and she just happens to have Down Syndrome. Soon after her birth, her mom shared a post that read, “Spread the word to end the word.” That was the first time I truly connected the dots that a word I used all my life could be used to describe this precious baby. I was appalled. Over the years, Haylie has grown into one of the most expressive (and bossy) children I know, and I love her to bits. Not for a millisecond has the R-word applied to that intelligent, loving, and feisty little girl.

The R-word directly hurt people I cared about. So I stopped using it.

The words “master/slave, blacklist/whitelist, black hat/white hat” are directly hurting people in our tech community. I care about them, so I stopped using the words. It really is that simple.

An Argument

Unfortunately, there are those who say it is, in fact, not that simple. These technological terms have always been used this way. Obviously, they aren’t about race; they are just the words we use.

A Rebuttal

Excuse me while I retrieve my eyeballs. They rolled so far back they got stuck behind my brain for a second.

I’ve got news for you. As I’ve personally proven, we can change our vocabulary. It takes a little conscious effort, at first, but it can be done. And it isn’t even that hard.

From a historical standpoint, it is perfectly logical that we would adopt new terminology. Language scholars will readily tell you that English, like all languages, is constantly evolving, primarily through changes in grammar, syntax, and – wait for it – vocabulary.

Words that were acceptable in the past are now some of our favorite swear words (NSFW - read “Swear Word History” by Kate Wiles). Others have been completely forgotten, such as the Middle English (think Canterbury Tales) word “clepped,” which means “called.” Don’t even get me started on Old English (think Beowulf). Just try to read Psalm 1 and tell me we haven’t changed a thing or two over the years.

While some of these changes can be attributed to a specific reason, many just simply changed. If we can stop using “clepped” and start using “called” just because surely we can change our vocabulary for an actual reason (Hint: the reason is our words are HURTING people in our community).

History proves words everyone used don’t have to stick around. Just because we once used these terms, doesn’t mean we need to continue to, especially when there are substitutes at the ready. It’s time to evolve.

How to Change Your GitHub Branches

So let’s start small by changing our primary GitHub branches from master to main. Unfortunately, I do not know of an automated way to do this, so you will need to go through these steps for each of your repositories. I will be doing this myself over the coming days.

In your terminal:

$ git branch -master main
$ git push -u origin main

In your GitHub repository:

Click the Settings tab. On the side menu, click Branches. Select main from the dropdown. Click Update , confirm the change, and you’re done!

A Final Thought

In addition to ridding your technical projects of these insensitive terms, I would like to encourage you to consider what other words, currently present in your lexicon, might have an unintended effect on the people around you. The entry on Writing Inclusive Documentation in the Google Developer Documentation Style Guide is a great starting point if you need some ideas.

The bottom line is this: if we can adapt our vocabulary to make even one person feel heard and respected, why shouldn’t we?

COVIDiary pt. 10 - Our First Component

Audrea Cook — Thu, 11 Jun 2020 21:37:41 +0000

Welcome to Part 10 of the COVIDiary project! If you’re just joining us or missed a post, here’s what we’ve done so far:

This week, we’re FINALLY writing code that will actually render in our browser! Today, we’re going to build our Footer component. Though it’s a relatively simple piece of our application, I decided to start with it for a few reasons. First, the Footer is the only page element that will be consistent throughout our entire application. It also gives us the opportunity to practice using a few tools that will be used extensively in the coming weeks. Finally, its simplicity allows us to focus on some React basics without having to worry about the more nuanced aspects.

Stub the Component

Create a new file in your src/components folder called Footer.js. Because our component doesn’t need to hold state, we can keep it simple as a functional component. Let’s stub that out really quick:


import React from 'react';

const Footer = () => {
    return (
        <div>
            Hello World!
        </div>
    );
};

export default Footer;

Import the Footer

Let’s add our Footer to App.js so we can actually see our work in the browser.

In src/App.js


import Footer from './components/Footer';

Just before the closing </div> In the render() section, add our component:


<Footer />

In your terminal, run yarn start. This will open your application in the browser. Right now, it should look something like this:

Fill in the Details

Now that we’ve got our server up and running, let’s change that “Hello World” to something we actually want, shall we? From here on out, we’re working in components/Footer.js

First, let’s replace the <div> in our render() with <footer>. Then, we’ll add our logo and copyright information:


<footer>
  {/*Logo link to CodeWitch blog*/}
  <a href={'[http://codewitch.dev](http://codewitch.dev "http://codewitch.dev")'}
  /*Opens link in new tab*/
  target={'_blank'}
  rel={'noopener noreferrer'}>
    <img src={'./CodeWitchLogo.png'} alt="AudTheCodeWitch Logo" height='50px' />
  </a>

  {/*Copyright information*/}
  <p>©2020 Audrea Cook</p>

</footer>

Let’s also add links to our social media profiles. We’ll use free icons from fontAwesome. To do this, we need to install some more packages. In your terminal, run the following:

$ yarn add @fortawesome/fontawesome-svg-core @fortawesome/free-solid-svg-icons @fortawesome/react-fontawesome @fortawesome/free-brands-svg-icons @fortawesome/free-regular-svg-icons

When that is complete, import the icons by adding the following two lines to the top of your page:


import { FontAwesomeIcon } from '@fortawesome/react-fontawesome'
import { faGithub, faTwitter, faLinkedin } from '@fortawesome/free-brands-svg-icons'

While we’re adding imports, let’s also bring in the react-bootstrap components we’ll be using:


import ListGroup from "react-bootstrap/ListGroup";
import ListGroupItem from "react-bootstrap/ListGroupItem";

Now, we’re ready to add some more code to our <footer> element:


{/*Using a ListGroup to create buttons for external links*/}
<ListGroup horizontal={"sm"} /*Will display horizontally vs vertically for screens size sm and up*/>
  <ListGroupItem action /*turns item into link button*/ href='https://github.com/AudTheCodeWitch' target="_blank" rel={'noopener noreferrer'} >
    {/*icon + text description*/}
    <FontAwesomeIcon icon={faGithub} /> GitHub
  </ListGroupItem>

  <ListGroupItem action href='https://twitter.com/AudTheCodeWitch' target="_blank" rel={'noopener noreferrer'} >
    <FontAwesomeIcon icon={faTwitter} /> @audTheCodeWitch
  </ListGroupItem>

  <ListGroupItem action href='https://www.linkedin.com/in/audreacook/' target="_blank" rel={'noopener noreferrer'} >
      <FontAwesomeIcon icon={faLinkedin} /> LinkedIn
  </ListGroupItem>
</ListGroup>

If you save and refresh your browser, the footer should now look something like this:

Coming Up

Now that we’ve got our Footer component, we’re ready to keep building our application! Next week, we’ll tackle the Header, another component that will be shared on every page! From there, we’ll really start to bring our project to life!

COVIDiary pt. 9 - UX Design

Audrea Cook — Fri, 05 Jun 2020 19:56:17 +0000

Welcome to Part 9 of the COVIDiary project! If you’re just joining us or missed a post, here’s what we’ve done so far:

This week, we’re stepping away from the keyboard. Though the work we’re about to do is absolutely necessary for our sanity, it won’t involve a single line of code. In fact, if you want, you can complete all of today’s work with a pencil and paper!

What are we doing? We’re planning our website layout. We’ll build a sitemap to get a feel for what pages we actually need. Then, we’ll create wireframes to rough out our design.

Why Step Back?

I’ve made a few websites now, and, due to project deadlines, they were largely chaotic, head-long rushes to completion. It was both stressful and terribly inefficient. As a writer, I never worked without an outline. Why would I design an application without creating a plan?

By pausing to get the broad strokes of our application on paper, we’ll free up time, later on, to hone and fine-tune our work. We’ll be able to visualize how a user might interact with our app, and we can use that to inform our design choices. We will see, at a glance, which React components will be used over and over.

Drafting the Sitemap

Put simply, a sitemap is a list of pages on a website. There are different types of sitemaps for different uses, but today we’re just building an outline for planning purposes. From a development perspective, this is a crucial step.

When designing your sitemap, your user should be at the forefront of your mind. What are the most important features to the user? How many clicks do they need to make to get from one page to the next? Which links should always be available? Which pages should be protected with a login?

You can do this all on paper, but I used diagrams.net, which is useful for all sorts of diagrams, not just a sitemap. I also highly recommend it when designing your database structure.

Let’s get started.

First, I created a box for each page I knew I wanted in my application. Then, I rearranged the boxes and connected them with arrows that indicate the user flow. Finally, I grouped the navigation and footer links together, as they will appear on every page.

Drawing the Wireframes

A wireframe is a very basic sketch of a webpage. They are like a builder’s set of blueprints. With a wireframe, developers are able to visualize the placement of different elements on a page.

In many professional settings, a designer draws up the wireframes, and the developer writes the code that brings the plans to life. On personal projects or for smaller companies, however, we won’t always have that luxury.

Having never actually made official wireframes myself, I read a few articles before I began. There are tons of great resources out there, but it seemed the bottom line with wireframes is to keep it simple.

To sketch my wireframes, I grabbed a stack of 3x5 index cards and a marker. When constructing wireframes, many designers use a felt-tipped marker to prevent them from getting too detailed. I used one index card per page. I drew the wireframe on the blank side, and I used the lined side for any quick notes.

As you can see, the design for my home page is very simple. At a glance, I can see I want a few images (indicated by the boxed-x placeholder), a brief page intro, and a preview of three recent entries. I also know I want a horizontal navigation bar, and I have a general feel for what the footer should look like. After completing the rest of the wireframes, I can also tell which components will be used over and over, like the diary entries, for example.

If I were collaborating with another developer, now would be a great time to seek feedback and compare notes. We could then iterate on our initial ideas until we have a set of designs we’re both happy with.

Remember, these wireframes are your outline. They are loose sketches, and you aren’t married to any specific idea. Don’t stress too much over your designs at first. Just get some thoughts on paper. We’ll refine our ideas once we start coding.

Coming Up

Now that we’ve got a general idea of the pages and components we need to build, we’re ready to build our first React components!

Course Review: FreeCodeCamp’s Responsive Web Design

Audrea Cook — Sat, 30 May 2020 01:29:16 +0000

We’re taking a short break from COVIDiary, simply because I wanted to share something else I’ve been working on with you. Just last night, I completed freeCodeCamp’s Responsive Web Design course.

You may be thinking, “She completed Flatiron’s boot camp. Why is she doing freeCodeCamp now?” Here’s the thing: a friend of mine compared the learning experience at Flatiron to drinking from a firehose. It is a perfect analogy. We learned so much, so quickly, that it was often overwhelming. We didn’t have the opportunity to dive deep into concepts like accessibility or design. While Flatiron taught me a little about a lot, I am using this time during my job search as an opportunity to broaden my understanding and hone my craft as a developer.

Now that I have completed the first 300-hour course on freeCodeCamp (and am halfway through the second), I would like to share a few insights about their material.

Let me start by saying how truly impressed I was with this course. I have been working with HTML and CSS for over a decade, and I still learned so much.

The Curriculum

Let’s talk about the curriculum. The course is broken into 7 modules, plus a section of 5 projects at the end. Each lesson has a quick readme with a coding exercise. To advance to the next lesson, your code must pass the given tests.

Module 1: Introduction to Basic HTML and HTML5

Composed of 28 lessons, this module covers the very basics any beginner needs to start using HTML. This section starts with the traditional “Hello World” exercise and builds from there. Beginners will be introduced to common HTML elements and their purposes, including the semantic elements introduced in HTML5, such as header, footer, section, and article. Learners also practice building forms, lists, and adding images.

Again, this section covers the fundamentals. If you already have experience in HTML, it will only take a few minutes to complete. It will take a tad longer for true code newbies, but both this module and the next are very beginner friendly.

Module 2: Basic CSS

This 44-lesson module covers quite a bit of ground on the topic of CSS. Like the previous section, it covers the CSS fundamentals any beginner would need to know: how to use in-line styling, how to use CSS selectors, and how to assign id and class attributes to your HTML tags. From there, it begins to show the true power of CSS. Learners import fonts from a Google api. They learn the distinction between padding and margin, as well as the corresponding shorthand notations.

I was especially impressed to see lessons covering the usage of variables in CSS. Using variables is a great way to experiment with different color schemes and themes without spending ages trying to adjust each individual element.

Module 3: Applied Visual Design

This module consists of 52 lessons and is a blend of HTML and CSS. This section really highlights how CSS and HTML work together to create outstanding webpages. This was my first introduction into creating animations with CSS, and I found it extremely interesting. Learners also resize and position elements, choose and adjust colors, and create gradients.

Module 4: Applied Accessibility

For me, this was the most important module in the course. At 22 lessons long, it didn’t take much time to complete, but I learned so much about web accessibility. I especially appreciated the lessons that explained how to make your page more usable by screen readers. This was something I, never having needed such a device, hadn’t previously considered. This module also covers concepts such as choosing high-contrast color schemes to address colorblindness issues, use headings properly, and improve form accessibility with elements like label and fieldset.

Module 5: Responsive Web Design Principles

This module is short and sweet, at only 4 lessons. It explains how to create a media query and make images and other elements responsive, but I feel like this was the weakest section of the course.

In the future, I would love to see freeCodeCamp expand this section to discuss mobile-first vs desktop-first design approaches. A few lessons discussing important media query break-points would also be awesome. To supplement the section as it currently stands, I recommend reviewing the Media Queries section of w3schools’ Responsive Web Design module.

Module 6: CSS Flexbox

The final two modules cover some more advanced aspects of CSS. This 17-lesson section explains how to use flexbox to position elements within a container. While freeCodeCamp covers flexbox pretty well, I still find it to be a little confusing, especially for beginners. If you struggle with this section, I suggest reading A Complete Guide to Flexbox by CSS-Tricks. Their explanations and illustrations, coupled with freeCodeCamp’s exercises, really solidified this concept for me.

Module 7: CSS Grid

The final module is 22 lessons long, and covers grid, another tool for creating complex web layouts. Having used grid in previous projects (not to mention countless Neopets pages), I found this module to be a solid review. Learners create basic grids using grid-template-rows and grid-template-columns. After learning to adjust these grids, users then learn to align items within the grid as well as use the ever-helpful grid-template-areas.

The Projects

To complete this course, learners must create 5 separate pages, each with unique user stories to guide the design. FreeCodeCamp provides a CodePen.io example for each project, but they also give a huge amount of creative freedom.

I make no claims to being a designer. However, after quickly getting the tests to pass, I usually spent a few more hours playing with the CSS, tweaking things here and there, and trying new techniques learned throughout this course.

I chose to complete these projects using my own editor (RubyMine) instead of CodePen. I also created a GitHub repository for each project to track my code changes. Additionally, I used these projects as an opportunity to practice deploying sites to Heroku.

Here are my submissions for the 5 projects. Click the links to see them in action. Note that any forms don’t actually submit anywhere.

Tribute Page - A Tribute to Mequa
Survey Form - Aquarium Survey
Product Landing Page - Code Witch’s Tarot
Technical Documentation Page - Ruby for Basic Witches
Personal Portfolio Webpage - The Code Witch

Final Thoughts

Overall, I think freeCodeCamp has created an excellent course. Did it take me 300 hours to complete? Definitely not. Would it take that long for an absolute beginner? Possibly. Either way, the Responsive Web Design course is a solid review for experienced devs, and a great introductory course for code newbies.

If you have ANY interest in code or web design, I highly recommend starting with freeCodeCamp.

COVIDiary pt. 8 - Make the Connection

Audrea Cook — Thu, 21 May 2020 19:17:10 +0000

Welcome to Part 8 of the COVIDiary project! If you’re just joining us or missed a post, here’s what we’ve done so far:

This week, we’re going to shift focus to the front end. By the end of today, we will be able to retrieve data from our API!

Before we write any code, make sure your backend server is running. In CD-api, run rails s to fire it up. Leave that running and open your CD-Client repository in another window.

Write Fetch Requests

We’ll be working solely in /src/App.js today. We will write two separate, but extremely similar, fetch requests. Write your code in the App class but before the render() method.


// test fetch

  // the fetch requests will run when the App.js component mounts

  componentDidMount() {

    // fetch all the public entries

    fetch('http://localhost:3000/api/entries')

      // take the response and convert it to json

      .then(response => response.json())

      // take the resulting json and log it to the console

      .then(data => {

        console.log("All public entries:", data);

      })

      // if there is an error, log an error message to the console

      .catch((error) => {

        console.error('Public Entries Error:', error);

      });



    // fetch the first user's entries

    fetch('http://localhost:3000/api/users/1/entries')

      .then(response => response.json())

      .then(data => {

        console.log("single user's entries:", data);

      })

      .catch((error) => {

        console.error('Single User Entries Error:', error);

      });

  }

We can now test our connection to our backend server! Start your server using yarn start and open it in the browser. Open the browser console so you can see the fetch results!

Coming Up

Eureka! The front and back ends are communicating with one another! Next week, we’ll shift our focus to building out the front end so we can actually see something.

COVIDiary pt. 7 - A Little More Action

Audrea Cook — Fri, 15 May 2020 20:26:37 +0000

Welcome to Part 7 of the COVIDiary project! If you’re just joining us or missed a post, here’s what we’ve done so far:

This week, we’re going to continue work on the back end, in CD-API. By the end of today, we will have basic CRUD actions for our Users and their Entries.

Today’s post will be a little long. Get yourself a Pepsi and some snacks, and settle in, friends.

#public Class Method

If you’ll recall, we added the is_public boolean to our entries table. We want users to be able to decide if others can see their posts or not. When we fetch from api/entries, we should only see the entries that have been marked as public. Let’s add a class method to our Entry class in models/entry.rb:


  # returns all the entries where is_public equals true

  def self.public

    self.all.select {|entry| entry.is_public? == true}

  end

Controller Modifications

Right now, our controllers are basically empty. Let’s build them out a bit. For the moment, we want CRUD (Create, Read, Update/edit, Destroy/delete) actions for both Users and Entries. We will probably tweak these some once we start manipulating data from the front end, but we’ll have a solid start by the end of today.

Let’s start by building out our UsersController in controllers/api/users_controller.rb. As you look through the following code snippets, remember to read the comments, which are preceded by the # symbol.


class Api::UsersController < ApplicationController

  # GET api/users

  # This action lists ALL the users in our database

  def index

    users = User.all

    render json: UserSerializer.new(users)

  end

  # POST api/users

  # This action creates a new user, given the provided parameters

  def create

    user = User.create(user_params)

    if user.save

      render json: UserSerializer.new(user)

    else

      render json: { error: "Error creating user" }

    end

  end

  # GET api/users/:id

  # This action shows a specific user, determined by the :id parameter

  def show

    user = User.find(params[:id])

    render json: UserSerializer.new(user)

  end

  # PATCH api/users/:id/

  # This action allows a user to update his or her data.

  def update

    user = User.find(params[:id])

    if user.update(user_params)

      render json: UserSerializer.new(user)

    else

      render json: { error: "Error updating user" }

    end

  end

  # DELETE api/users/:id

  # This action completely removes a user from the database

  # We may want to update this later to also destroy a user's entries

  def destroy

    user = User.find(params[:id])

    user.destroy

  end

  private

  # Determine which parameters to allow from a form submission

  def user_params

    params.require(:user).permit(

        :id,

        :first_name,

        :last_name,

        :email,

        :birth_date,

        :occupation,

        :is_essential,

        :isolation_start,

        :isolation_end,

        :about

    )

  end

end

Are you still with me?

Let’s add the CRUD actions for our EntriesController in controllers/api/entries_controller.rb.


class Api::EntriesController < ApplicationController

# before we call a controller action, call the #set_user private method

  before_action :set_user

  # GET api/users/:user_id/entries OR api/entries

  # This action lists ALL the entries in the database OR all the entries for a given user.

  def index

    # if there is a user in the params, only show their entries. 

    # Otherwise, only show the public entries.

    # TODO: edit user entries so they only show private ones if it is the current user

    entries = @user ? @user.entries : Entry.public

    options = {

        include: [:user]

    }

    render json: EntrySerializer.new(entries, options)

  end

  # POST api/users/:user_id/entries

  # This action creates a new entry assigned to a given user

  def create

    entry = @user.entries.build(entry_params)

    if entry.save

      render json: EntrySerializer.new(entry)

    else

      render json: { error: "Error creating entry" }

    end

  end

  # GET api/users/:user_id/entries/:id

  # This action shows a specific entry for a given user

  def show

    entry = Entry.find(params[:id])

    options = {

        include: [:user]

    }

    render json: EntrySerializer.new(entry, options)

  end

  # PATCH api/users/:user_id/entries/:id

  # This action allows a user to update his or her entry.

  def update

    entry = Entry.find(params[:id])

    if entry.update(entry_params)

      render json: EntrySerializer.new(entry)

    else

      render json: { error: "Error updating entry" }

    end

  end

  # DELETE api/users/:user_id/entries/:id

  # This action completely removes an entry from the database

  def destroy

    entry = Entry.find(params[:id])

    entry.destroy

  end

  private

  # This method allows us to find a specific user 

  def set_user

    if params[:user_id]

      @user = User.find(params[:user_id])

    end

  end

  # Determine which parameters to allow from a form submission

  def entry_params

    params.require(:entry).permit(

        :id,

        :user_id,

        :health_rating,

        :is_symptomatic,

        :health_comments,

        :mental_health_rating,

        :mental_health_comments,

        :diary_entry,

        :is_public,

    :created_at

    )

  end

end

Coming Up

Our back end is ready to deliver information to the Client app. Next week, we’ll test that connection with a few fetch() requests to make sure everything is running smoothly.

COVIDiary pt. 6 - Formatting Data

Audrea Cook — Thu, 07 May 2020 19:54:52 +0000

Welcome to Part 6 of the COVIDiary project! If you’re just joining us or missed a post, here’s what we’ve done so far:

This week, we’re working on the back end. By the end of today, we will:

Add some important gems
Generate serializers to properly format our data

Are you ready? Let’s do this.

Open your CD-API repository.

1. Add Gems

We need to add two more gems to our Gemfile to help the front and back ends communicate properly.

Rack CORS Middleware

The first is Rack CORS Middleware, which will let our fetch requests work. Rack CORS is used so frequently in Rails applications that it’s automatically included in your Gemfile. To use it, simply uncomment the line in your Gemfile.

# Use Rack CORS for handling Cross-Origin Resource Sharing (CORS), making cross-origin AJAX possible
gem 'rack-cors'

We also need to uncomment the following section in config/initializers/cors.rb:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'example.com'

    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head]
  end
end

Finally, change example.com to * for now.

Fast JSON API

The second gem we need to add is Fast JSON API. This will allow us to generate serializers and properly format our data before sending it to the front end. You can read more about serializers here. In your Gemfile, add the following:

gem ‘fast_jsonapi’

That’s it! Now that we’ve added both gems, let’s install them by running bundle install in your terminal. You can also start up your backend server now using rails s.

2. Generate Serializers

We need a serializer for both our Entries and our Users.

With Fast JSON API, these are easy to create with the rails g serializer command. Let’s do that now. In your terminal, enter the following:

rails g serializer Entry
rails g serializer User

You will now have a serializers directory in your app directory, and it will contain your two new serializer files. They should look something like this:

class EntrySerializer
  include FastJsonapi::ObjectSerializer
  attributes 
end

Let’s configure these to present the data the way we want. First, we’ll add our relationships. A user has many entries, so in your UserSerializer class, add:

has_many :entries

We’ll set up the opposite side of the relationship in your EntrySerializer class:

Belongs_to :user

Now that we have the relationships under control, we need to specify which data attributes we want to serialize. In your EntrySerializer class, change the attributes line to look like the following:

attributes :id,
             :health_rating,
             :is_symptomatic,
             :health_comments,
             :mental_health_rating,
             :mental_health_comments,
             :diary_entry,
             :is_public,
             :created_at

Now do the same with the UserSerializer class:

attributes :id,
             :first_name,
             :last_name,
             :email,
             :birth_date,
             :occupation,
             :is_essential,
             :isolation_start,
             :isolation_end,
             :about

Coming Up

We now have serializers to properly format our data for future fetch() requests!! Next week, we’ll create our controller actions so we can finally connect to the front end!

COVIDiary pt. 5 - Backend Routing

Audrea Cook — Fri, 01 May 2020 21:07:44 +0000

Welcome to Part 5 of the COVIDiary project! If you’re just joining us or missed a post, here’s what we’ve done so far:

This week’s post was super duper long, and it covered lots and lots of code across the front and back end. My inner editor put her foot down, and I have now broken that massive tome into not one, but four smaller posts that focus on specific concepts or tasks.

If you want to skip ahead, you can check out my progress in the CD-API and CD-Client repositories on GitHub. I’ll continue working on the project as these blog posts release over the coming weeks.

Today, we’re going to work on the back end. By the end of today, we will have all our backend routing configured and ready to go.

Open your CD-API repository.

Namespace Routes

We’ll start by configuring our routes. We want to add /api to our backend routes so we can better keep things straight.

To keep our files organized, make an /api directory in your /controllers directory, and place your controllers within it.

Note: You probably don’t have the users_controller.rb yet. If that’s the case, now is a perfect time to add it. In your terminal, run rails g controller api/users.

Now we’ll wrap our resources within an /api namespace in our config/routes.rb file:


rails.application.routes.draw do

  # wrap routes in /api namespace

  namespace :api do

    # create index route for all entries at /api/entries

    resources :entries

    # create routes for users at /api/users

    resources :users

  end

end

We only want /api/entries so we can see the list of all public entries. We want to nest our CRUD actions for specific entries under specific users. Let’s make some minor changes to accomplish this.


rails.application.routes.draw do

  namespace :api do

    # creates index route for all entries at /api/entries

    resources :entries, only: [:index]

    resources :users do

      # create all CRUD routes for a specific user's entries at api/users/:user_id/entries

      resources :entries

    end

  end

end

At this point, you can run rails routes in your terminal to see all the routes we’ve just created.

Coming Up

We are one step closer to hooking up our front and back ends. Next week, we’ll format our data so we can send it to our client app. We’re making progress!

COVIDiary pt. 4.5 - Database Fixes

Audrea Cook — Fri, 24 Apr 2020 16:21:20 +0000

Welcome to Part 4.5 of the COVIDiary project! If you’re just joining us or missed a post, here’s what we’ve done so far:

This week, we’re going to work on our PostgreSQL database in the CD-api directory. By the end of today, we will:

Fix improper boolean names
Add is_public boolean to entries
Update seed file
Reset database

Ch-ch-ch-CHANGES

I was reading up on naming conventions this week, and I came across this article. I realized the boolean names in our tables did not follow best practices, and I set about changing them.

I’m going to go into Part 3 and fix the mistakes I made. If you’ve been coding along with me, check out the video below to see how to make the changes yourself!

Coming Up

Next week, we’ll work on setting up our routes, serializers, and controllers so the front and back ends can talk to one another. Until then, stay well!