DEV Community: Matthew Palmer

Introduction to SASS

Matthew Palmer — Tue, 16 Mar 2021 20:12:22 +0000

Introduction

Sass (or SCSS) is an extremely powerful design tool for developers. It takes care of all the heavy lifting of regular old CSS, and so much more... A lot of new developers are afraid of it for some reason (I was too!), but you'll fall in love so fast! In fact, by the end of this blog, I'd be willing to bet your whole design game will forever change. Buckle up, this is going to be fun. 😉

Installation

This walkthrough will require VsCode. I'm sure there are other IDEs you can use, but we're going to be using a couple specific extensions.

Step 1:

Install "Live Server" by Ritwick Day

Step 2:

Install "Live Sass Compiler" by Ritwick Day

Wow, that was easy! Let's get to the fun part.

Setup

At this point, you'll want to start a new, empty project. Include an index.html file. Inside of index.html, type ! and press enter to create a very basic HTML boilerplate.

Or just copy this one:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Sass Sandbox</title>

    <!-- CSS -->
    <link rel="stylesheet" href="./styles/styles.css">
</head>
<body>
    <div id="root">
        <header>
            <h1>Sass Sandbox</h1>
        </header>
        <div class="container">
            <h1>Welcome to the...pratice box...thing....</h1>
            <p>Lorem ipsum, dolor sit amet consectetur adipisicing elit. Dolor consequuntur fugit magni esse, exercitationem nisi eius ipsa commodi! Quod saepe dignissimos vel accusamus ducimus iste nam quam officia, similique neque?</p>
            <button>Here is button #1</button>
            <div>
                <button>Curvball, but here's a button in a DIV</button>
            </div>
        </div>
    </div>
</body>
</html>

You'll notice the ./styles/styles.css is included, and it doesn't end in .scss. This is because browsers can't read .scss files. We will be using Live Sass Compiler to compile our styles.scss file into styles.css. You'll find out how we do this next.

In the same directory, create a folder called styles. Inside of styles, place a new file called styles.scss.

Done? Great! Let's learn how Sass works!

Working with Sass

For the sake of keeping things consistent and less confusing, we're going to work off the boilerplate I included above.

Inside of your styles.scss, we can start including some normal CSS, like so:

body {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

Looks normal, right?
Well, let's activate our Live Sass Compiler. At the bottom of your VsCode, you should see a button that says "Watch Sass".

Click this, and watch the magic happen! Now you'll have a generated styles.css along with styles.css.map. The latter isn't important, so let's open styles.css.

NOTE: If you don't have autosave enabled on your VsCode, you will need to manually save your changes by pressing CTRL + S

Notice how it's slightly different looking?

body {
  margin: 0;
  padding: 0;
  -webkit-box-sizing: border-box;
          box-sizing: border-box;
}

This is only the beginning. 😉 Sass takes care of not only setting properties, but it sets your styles up to work across all browsers. Regular CSS can do this, but it takes a significant amount of effort to apply by hand.

Let's take a look at a more complex compile. Place this in your Sass file:

header {
    display: flex;
    box-shadow: 0 0 50px -20px black;
    justify-content: center;
    align-items: center;
    font-size: 3rem;
    width: 100vw;
    height: 200px;
    background-color: rgb(178, 178, 209);
}

Now, get ready. This is what all of those properties look like when compiled for all browsers:

header {
  display: -webkit-box;
  display: -ms-flexbox;
  display: flex;
  -webkit-box-shadow: 0 0 50px -20px black;
          box-shadow: 0 0 50px -20px black;
  -webkit-box-pack: center;
      -ms-flex-pack: center;
          justify-content: center;
  -webkit-box-align: center;
      -ms-flex-align: center;
          align-items: center;
  font-size: 3rem;
  width: 100vw;
  height: 200px;
  background-color: #b2b2d1;
}

Wonderful! Sass is already starting to set off the dopamine in your brain, isn't it? Surprise, it gets better. Now we're going to learn about using variables.

Sass Variables

Wouldn't it be amazing if we could use variables in Sass like we do in, say, JavaScript? Wait... we can! Imagine that you have a specific color that you use throughout a really huge application. Among the CSS properties it's used in, you can probably imagine how much of a pain it would be to go and change every single one when you change your color scheme.

Enter in Sass variables. Here is how we would set one at the top of our Sass file:

$myNewSassColor: lightblue;

Now we can change the background color in our header style:

header {
    display: flex;
    box-shadow: 0 0 50px -20px black;
    justify-content: center;
    align-items: center;
    font-size: 3rem;
    width: 100vw;
    height: 200px;
    background-color: $myNewSassColor;
}

This is a very simple, narrow case but I'm sure you can see the benefit at a much larger scale. Hypothetically speaking, if you end up with 100 elements with the same background-color, I'm sure you'd agree that changing a single variable VS changing 100 styles is preferred!

Now, let's talking about nesting.

Sass Nesting

If you've ever tried tackling a project using pure CSS, you know how crazy it can get. Addressing each sub-element can turn into a nightmare. At least far as I'm concerned, it's caused me to burn out very quickly after hours of design work.

Take a look at this raw CSS:

.container {
  display: -webkit-box;
  display: -ms-flexbox;
  display: flex;
  -webkit-box-orient: vertical;
  -webkit-box-direction: normal;
      -ms-flex-direction: column;
          flex-direction: column;
  -webkit-box-pack: center;
      -ms-flex-pack: center;
          justify-content: center;
  -webkit-box-align: center;
      -ms-flex-align: center;
          align-items: center;
  width: 100%;
}

.container h1 {
  font-size: 3em;
  margin: 0;
}

.container p {
  width: 50%;
}

.container button {
  color: red;
}

☝️ This is what will be returned after this 👇 Sass compiles:

.container {
    display: flex;
    flex-direction: column;
    justify-content: center;
    align-items: center;
    width: 100%;

    h1 {
        font-size: 3em;
        margin: 0;
    }

    p {
        width: 50%;
    }

    button {
        color: red;
    }
}

This is Sass nesting! It's much cleaner, easier to read and easier to manage. Pseudo-selectors are handled differently as well, but still in a pleasing way:

h1 {
    font-size: 3em;
    margin: 0;
    &:hover {
        color: red;
    }
}

Imports

Sass also allows us to import from other Sass files. These files start with an underscore. Let's assume you have a file named _anotherSassFile.scss.

You can write your styles in styles.scss still, but this allows us to separate by concern. We can build a Sass file for our navigation bar, one for our home page, one for a dashboard, etc. All you have to do in order to use the imports is placing @import './anotherSassFile.scss' at the top of styles.scss & you're good to go!

Sass Mixins

Mixins are similar to functions in JavaScript, and they allow us to condense repeated code into a single Mixin.

As a frontend developer, let's be honest -- You're using these properties A LOT! :

.someClass {
    display: flex;
    justify-content: center;
    align-items: center;
}

Those three properties are damn near the bread and butter for a lot of our designs, but we have to repeat ourselves over and over. Let's make using them a little easier...

@mixin flexCenter {
    display: flex;
    justify-content: center;
    align-items: center;
}

Our @mixin has a variable name of flexCenter. You can name it whatever you want. Whatever makes more sense to you. But now, look at how we can use it:

.someClass {
    @include flexCenter();
}

From three lines down to one! Do you love Sass yet? No!? Still not convinced? Okay, fine. I get it. You're all about the fancy things in life. You don't like your cake without icing. Heard, then check this next part out:

@mixin Variables

You can make dynamic mixins. I'll just show this one to you:

@mixin flexCenter($direction) {
    display: flex;
    justify-content: center;
    align-items: center;
    flex-direction: $direction
}

.someClass {
    @include flexCenter(column);
}

Would you just LOOK AT THAT? Sass allows us to set arguments, and they work! Enjoy that icing, buddy.

Conclusion

Sass is a very powerful tool capable of changing the way we design our web pages. From nesting to variables to mixins (basically functions), Sass completely changes the game. If you haven't found a reason to dive in yet, hopefully I've done a great job at convincing you today.

Happy Tuesday, everyone!

IF nothing ELSE, ternary...

Matthew Palmer — Tue, 09 Mar 2021 21:28:59 +0000

Introduction

There's a little somethin' somethin' I've seen in other projects. The overuse of IF ELSE statements. Or should I say the improper use of them. The inefficient, ugly use of them. Let's talk about that.

The Ternary Operator

This is an amazing tool. Not only does it execute conditionals, it offers a clean code solution to an otherwise line greedy block of code. Take a look:

if(100 === +"100") {
    console.log("YES! WE DID IT! 100%");
} else {
    console.log("YOU BATHE IN LIES!");
}

This isn't too bad, but it is definitely taking up way too many lines. Try this instead:

100 === +"100" ? console.log("YES! WE DID IT! 100%") : console.log("YOU BATHE IN LIES!")

We went from 5 lines of code down to one! Confused? Let's break it down in a simple manner.

conditionIsTrue ? doThisIfTrue : doThisIfFalse

It is almost the same as an IF ELSE statement, but know when you can use it and when you can't. Ternary operators are only meant to replace IF ELSE statements that only accept a single line response.

Example:

if(condition) {
   performThisAction();
   AaaandThenDoThisAction();
} else {
   doSomeOtherAction();
}

This would not work with ternary.... This is because the if statement takes two actions when one condition is true. A ternary operator can only perform one action dependent on whether the given condition is true or not. There is a time and place for both the if statement and the ternary operator. Proper use of them is highly dependent on understand how they work, when and why we use them.

Conclusion

JavaScript has many useful tools, but there's an old saying you more than likely have heard before.... "with great power comes great responsibility". Code smarter, not harder. If nothing else, write code that is kind to others. If it takes up too much room and is unreadable, it's not very kind!

Happy Tuesday!

React Calculator (Oh god...)

Matthew Palmer — Tue, 02 Mar 2021 23:42:10 +0000

Introduction

Calculators are all fun and games until you start thinking about all the ridiculous edge cases. Travel down this rabbit hole with me...

Operators & Parenthesis

Let's start off with talking about why these edge cases are so important. Let's assume you have an equation: 34+45*(34

Now, when you try to evaluate this... What do you think happens? It's a no brainer, you're gonna get an error. How do we fix it then? End users are creative, oblivious, and they definitely wont use our calculator in the exact way we created it to be used. At the very least, they wont all follow a logical pattern. So, one method you might go with is something along the lines of eval(result + ")"). Awesome, that solves the problem!

Well... it solves that VERY NARROW problem. What happens when they type 34+45*(7)*(. Chances are, your fix accounted for whether ( and ) exist. They both exist now, and we've run into the same problem as before, but now it's advanced. So we now check to see if the very END of our equation includes a ( or with a number like (4. Depending on the case, we either remove the ( or add a ).

Operators (+, -, *, /)

Operators are a bit easier to handle. We basically check if the most recent item in the equation is an operator. If it is, either we replace it or keep it the same (if we chose the exact same operator again).

This is how I handled it:

const handleOperator = e => {
        let newResult = result.split("");
        let checker = newResult[newResult.length - 1]

        // Checks if an operator already exists at the end of the operation
        // If it does, replace it with the one that was clicked
        if(checker === "+" || checker === "-" || checker === "*" || checker === "/") {
            newResult.pop()
        }
        const joiner = newResult.join("")
        setResult(joiner + e.target.value)
    }

Conclusion

Okay, today this post was a very quick one. But I believe it highlights the complexity in simplicity. Once of the easiest projects we've ever worked on as developers has been a calculator. However, I strongly believe we underestimate just how complex calculators can be. It's not as easy as mapping buttons and having a great 'ol time. There are so many use-cases that need to be accounted for, and I've likely not truly covered them all today. If there is anyone else out there reading this and going through the same thing, I hope this post provides some perspective. It's the result of hours of headache and burnout trying to think things through.

Happy Tuesday, everyone!

React + Tailwind

Matthew Palmer — Tue, 23 Feb 2021 22:03:23 +0000

Introduction

Tailwind has proven itself to be quite the handy CSS framework. Similar to Bootstrap, except more flexibility and customization. There are other options out there when it comes to choosing a framework in React, but Tailwind just makes sense to me. So today I'd like to share a very easy way to get it set up in React!

Installing Tailwind

Step 1: Dependency

The first thing you want to do (assuming you have Node.js), is to npm install tailwindcss. This will save it as a dependency to your project.

Step 2: tailwind.css

Create a tailwind.css file under your src/ file. Next, include these contents inside:

@tailwind base;
@tailwind components;
@tailwind utilities;

Step 3: Scripts

Next, we need to enable tailwind to compile the CSS together in a new file when our application runs. To do this, we need to run some prebuild scripts. Head into your package.json and update the script with this:

"scripts": {
    "build:tailwind": "tailwindcss build src/tailwind.css -o src/tailwind.output.css",
    "prestart": "npm run build:tailwind",
    "prebuild": "npm run build:tailwind",
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  },

This will ultimately create a new tailwind.output.css file when we run our application.

Step 4: Making it accessible

Now we just need to make tailwind.output.css accessible to our entire application. Head over to index.js and place this line anywhere at the top of the file:

import './tailwind.output.css';

And it's that easy! You're all set to use Tailwind in your React application. Just fire it up with npm start!

Conclusion

As someone who isn't quite an expert designer, I find that Tailwind works well even in more advanced applications/libraries. Design is its own beast, and it is easy to get lost in crafting UI alone before getting into the nitty gritty logic of your app. It's better to streamline the design and make it all work before making it pretty.

I hope you guys enjoyed this quick setup tutorial!
Happy Tuesday! 🎉

Rails - find VS find_by

Matthew Palmer — Tue, 16 Feb 2021 23:13:52 +0000

Introduction

In the beginning of my Rails journey, find_by became the bane of my existence, and I didn't even know how, why, or what was happening. Everything was perfectly fine when testing out a new account or creating a new object after database migration. I mean, they were the first objects in the database. Of course everything would go well. Until it came down to testing gated content/permissions between two users...

What is `find_by`?

This is probably the first question I should have asked myself. Don't you know what the say about assuming? I did a lot of that, and I paid for it with hours and hours of stubborn frustration. To begin with, find_by isn't what you think it is. It returns the first item in the database. Even if you edit an item on a TODO list with an id of 27, user_id of 6, and description of "Buy Chocolate Milk", using find_by in your controller will return the very first item you didn't specifically query for. That's what find is for.

What is `find`?

It's how we retrieve the exact data we queried for, and the data must match the criteria. With find, it doesn't loosely choose anything that might be related to the condition we pass in. This would have saved me hours of headache if I had given myself the time to understand them. But they have definitely changed the progress I've made in my projects ever since.

Ever heard of `where`?

In my searches, I came across this super neat bonus. If you're like me and wondered what the purpose of it is compared to find or find_by, where returns a collection of all items that match a certain criteria. If there are no results, it returns an empty object. Unlike the others which throw an exception error.

Conclusion

Sometimes, syntax doesn't mean what you think it means. If you make assumptions, you'll get some unexpected behavior. You'll have to do some research, but along the way you might learn about some tools that are a bit cooler and more useful than the one you're using. When in doubt, things go wrong for a good reason and it usually has something to do with what you don't understand about the code you're using.

Happy Tuesday!

componentDidMount() VS useEffect()

Matthew Palmer — Wed, 10 Feb 2021 01:49:41 +0000

Introduction

These two were the bane of my existence this week, and I think now is as good a time as any to talk about them.

React

Starting off in React, hooks are usually far from our first lesson. We deal with Components and Pure Components before we typically find a reason to use Functional Components. It wasn't until after I started learning Hooks that I realized they only work in Functional Components. This was huge because the first case I ran into where I needed a convenient way to redirect to another page, which was with the useHistory hook from react-router-dom. A whole new world opened up for me, but not all was well...

Conditional rendering

Here I am at a crossroads. This component needed to render based on a boolean. Is there a user signed in? Is their id equal to this object.user_id? If it's not, then I wanna history.push("/")!

But wait... useEffect, AND useLayoutEffect for that matter, will fire after the conditional rendering. Therefore, the object.user_id will never exist. Even with componentDidMount(), the conditionals run while the component mounts!

When both go wrong...

I took a different approach when I realized that neither tool would work for me. I required a conditional with my server response. Checking for an error before rendering to the page.
As it turns out, there are cases when certain code needs to be validated before API calls and hooks in general.

My workaround though? Put redirects in the API call rather than returning it with a component. Chances are, it's better to redirect before state has a chance to update your pages if a user was never authorized to view that content to begin with!

Here's a small snippet in case it helps anyone out there!

    useEffect(() => {
        let listID = props.match.url.split("/")[3];

        api.list.editUserListByUrl(listID)
        .then(resp => {
            if(!resp.err) {
                setUserID(+resp.listitem.user_id)
                setUrl(resp.listitem.url)
                setDescription(resp.listitem.description)
            } else {
                history.push("/dashboard");
            }
        })
    })

Happy Tuesday, everyone!

DIY Function APIs

Matthew Palmer — Tue, 02 Feb 2021 17:46:23 +0000

Introduction

Sometimes, our applications can get really crazy. Especially when your backend API calls become abundant in numbers. Here's how I managed to organize my API calls better -- Specifically, in React!

The Problem

When we make API calls, the most common method is a fetch request. Some people use axios (which is really great!), but I'm going to keep things mostly vanilla today. 😉

A common fetch request, such as a POST, looks like this:

fetch("https://some-website.com/some-api-data", {
    method: "POST",
    headers: {
        "Content-Type": "application/json",
        Accept: "application/json",
        Authorization: "someRandomTokenHere-bckjhbdhkcjbdh"
    },
    body: JSON.stringify({data: {someDataKey: someDataValue}})
})
.then(resp => resp.json())
.then(resp => performSomeFunc())
.catch(error => console.log(error))

Now, I get it! Copy & Paste can be really useful here. (Thanks Larry Tesler! 🙏 RIP). But, why do that when we could do something better? Something that could cut down on code clutter... make things pretty... like, a Function API!

What is a function API?

Simply put -- It's an API of functions!

Check this out below. In my React project, I've created a folder under src called services. In services is a JavaScript file named api.js:

export const API_ROOT = "http://localhost:3000/api/v1"

const token = () => localStorage.getItem("token");

const headers = () => {
    return {
        "Content-Type": "application/json",
        Accept: "application/json",
        Authorization: token()
    };
};

// data will be nested objects...  ex. {user: {id: ...}}

const login = data => {
    return fetch(`${API_ROOT}/login`, {
        method: "POST",
        headers: headers(),
        body: JSON.stringify(data)
    }).then(resp => resp.json());
}

const newUser = data => {
    return fetch(`${API_ROOT}/users`, {
        method: "POST",
        headers: headers(),
        body: JSON.stringify(data)
    }).then(resp => resp.json())
}

const getCurrentSession = () => {
    return fetch(`${API_ROOT}/current_session`, {
        headers: headers()
    }).then(resp => resp.json());
};

const updateUser = data => {
    return fetch(`${API_ROOT}/users/${data.user.id}`, {
        method: "PUT",
        headers: headers(),
        body: JSON.stringify(data)
    }).then(resp => resp.json());
};

const getUserList = data => {
    return fetch(`${API_ROOT}/users/${data.user.id}/list`, {
        method: "POST",
        headers: headers(),
        body: JSON.stringify(data)
    }).then(resp => resp.json())
};

const getUserListByUrl = data => {
    return fetch(`${API_ROOT}/users/public/list`, {
        method: "POST",
        headers: headers(),
        body: JSON.stringify(data)
    }).then(resp => resp.json())
};

const addToUserList = data => {
    return fetch(`${API_ROOT}/users/list/add`, {
        method: "POST",
        headers: headers(),
        body: JSON.stringify(data)
    }).then(resp => resp.json())
};

const deleteUser = user_id => {
    return fetch(`${API_ROOT}/users/${user_id}`, {
        method: "DELETE",
        headers: headers(),
    }).then(resp => resp.json());
};

const deleteItem = listitem_id => {
    return fetch(`${API_ROOT}/listitem/${listitem_id}/delete`, {
        method: "DELETE",
        headers: headers(),
    }).then(resp => resp.json())
};

export const api = {
    auth: {
        login,
        getCurrentSession,
    },
    user: {
        newUser,
        updateUser,
        deleteUser,
        getUserList,
    },
    list: {
        getUserList,
        getUserListByUrl,
        addToUserList,
        deleteItem,
    }
}

You'll notice right at the bottom that I've created an API / data structure containing all of our functions in organized categories. Now, we can catch a glimpse of how much cleaner this will make our code!

`componentWillUpdate()` and Function APIs

Assuming we want to check a user's session (if they are logged in), this is what our functional component might look like:

import React, {useEffect} from 'react';
import { api } from '../services/api.js'

export default function dashboard(data) {

    const validateUserSession = () => {
        // some unique code here that validates a user in your app
    }

    useEffect(() => {
        api.auth.getCurrentSession()
        .then(resp => validateUserSession())
    })

    return (
        <div>
            <p>If you're reading this, you're awesome!</p>
        </div>
    )
}

Wonderful! Our useEffect hook runs when the page loads which executes a much more drawn out process (one that we defined in our Function API). It's CLEAN, it's DRY, and it's much more readable on a team.

Conclusion

I think this is one of the most useful methods for maintaining many API calls. Without them, it's easy to lose track of each call or even waste time typing them out or finding them somewhere else you already used them! Ahh, the headaches involved... but, I hope that you guys can take this and run with it! It makes us all better developers. 😉

Happy Tuesday!

React useState State Hook

Matthew Palmer — Sun, 24 Jan 2021 20:04:46 +0000

Introduction

One of the biggest perks about React is the ability to maintain state both in a component and at the top level of your application if you include a state=management package such as Redux. Today, I want to talk about the React State Hook and how it has changed the way we manage state and, most importantly, cleaned up the code involved!

At A Glance

Looking towards the docs for useState(), we catch a glimpse of how we go about using it:

import React, { useState } from 'react';

function Example() {
  // Declare a new state variable, which we'll call "count"
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click me
      </button>
    </div>
  );
}

I'm going to explain what's happening, but let's visit the old way doing things below:

import React, { Component } from 'react';

export default class Example extends Component {
    constructor(props) {
        super(props)
        this.state = {
            count: 0
        }
    }

    handleClick = () => {
        this.setState({ count: count + 1})
    }

    render() {
        return (
            <div>
                <p>You clicked {this.state.count} times</p>
                <button onClick={this.handleClick}>
                    Click me
                </button>
            </div>
       );
    }
}

Geeze, that's a lot of population in our code for something so simple. Enter useState...

How `useState` Is Applied

If we pay attention to this line: const [count, setCount] = useState(0);, you'll see a deconstructed method for handling the state of count. The setCount method acts as a function that compares to triggering this.setState({}) in the older way of handling state changes.

This can be seen where it is applied in the code snippet above for our button:

<button onClick={() => setCount(count + 1)}>
    Click me
</button>

setCount is handling all of our logic which would normally be way more drawn out. Thanks to our React State Hook, our code is way more clean and readable.

Conclusion

React Hooks are incredible useful and time saving. There are more of them out there, and they all solve a problem that we developers would otherwise run into at some point or another. If you're new to React, this is going to change the game for you! Please enjoy, and as always, leave a comment if you have any questions!

Happy Sunday!

Let's Talk Functional Components & Hooks

Matthew Palmer — Tue, 19 Jan 2021 21:49:19 +0000

Introduction

As someone who has primarily used React Components and React Pure Components, I'll admit -- I got WAY too comfortable. So comfortable, in fact, that I was missing out completely. It wasn't until I started working on my current project that I needed an efficient way to redirect users based on an action. Naturally, I stumbled upon two hooks: useEffect and useHistory. Let's talk about them.

The `useHistory` Hook

This hook was the answer to my redirect problems. It is perfect and easy to use. Here's the problem... you can't use this hook inside of a React Class Component or React Pure Component. It will throw an error that tells you to use a Functional Component. This is the point in which I stepped into a new world.

How do we even USE `useHistory`?

Here's a little snippet that shows how to properly use the useHistory hook:

import React, { useEffect } from 'react';
import { useHistory } from 'react-router-dom';
import { api } from '../services/api.js';

export default function Dashboard(props) {
    const { authUser } = props;
    let history = useHistory();

    useEffect(() => {
        api.user.getUserList({user: authUser})
        .then(resp => console.log(resp))
    });

    return (
        <>
            {authUser.id ? (
                <>
                    <div>Hello {authUser.username}</div>
                </>
            ) : (
                history.push("/")
            )}
        </>
    )
}

Basically, if information is passed into this Dashboard and there is no authenticated user in props, this functional component will redirect the user back to the home screen or landing page.

What is a Functional Component?

Let's explore what this is for a moment. First, let's take a look at a React Class Component:

import React, { Component } from 'react';

export default class Animal extends Component {
    render() {
        return (
            <div>

            </div>
        )
    }
}

Compare that with a functional component:

import React from 'react';

export default function Animal() {
    return (
        <div>

        </div>
    )
}

As we can all see, there is a major difference between the two. For starters, it's much easier to pass in props in this way if we wanted to. But the big kicker is that we can take full advantage of React Hooks. Let's say that you need to fetch data upon the rendering of a component. Your React Class Component would look like this:

import React, { Component } from 'react';

export default class Animal extends Component {

    componentDidMount() {
       fetch("https://some-url.com/api")
       .then(resp => resp.json())
       .then(data => performSomeActionWith(data))
       .catch(err => console.log(err))
    }

    render() {
        return (
            <div>

            </div>
        )
    }
}

This will do the almost the same thing as useEffect:

import React, { useEffect } from 'react';

useEffect(() => {
    fetch("https://some-url.com/api")
    .then(resp => resp.json())
    .then(data => performSomeActionWith(data))
    .catch(err => console.log(err))
});

export default function Animal() {
    return (
        <div>

        </div>
    )
}

The difference between componentDidMount and useEffect is important to understand, however. They are not the same. According to this source:

componentDidMount and useEffect run after the mount. However useEffect runs after the paint has been committed to the screen as opposed to before. This means you would get a flicker if you needed to read from the DOM, then synchronously set state to make new UI.

Conclusion

The purpose of this blog was to introduce React hooks and how to properly use them with functional components. However, it is important to not only understand how to use them but also WHY we use them -- What purpose do they serve and what problems do they solve? There are so many more hooks, and I encourage you to run off and explore them all! Leave a comment if you'd like to see a blog covering nothing BUT hooks. ;)

Thanks for reading! Happy coding!

localStorage with JWT Web Tokens

Matthew Palmer — Tue, 12 Jan 2021 21:34:39 +0000

Introduction

Security in web applications is a must. Especially when you're scaling up with a gigantic platform. Securing your websites doesn't make them invulnerable, but they certainly do the job of preventing as many disasters down the line as possible. Even tech giants like Facebook, Twitter, Google and Amazon have experienced a security breach at one point or another. So today, let's talk about one of my favorites -- JWT Web Tokens with localStorage. For the sake of this blog, you'll need to be familiar with Ruby on Rails.

What are JWT Web Tokens?

They are JSON Web Tokens. In other words, they are encrypted "keys" to all the doors a user can open with their account. Including the most important -- signing into it! It's basically a handshake between the client and server that says, "Okay, you are who you say you are. You are permitted to perform this action." Sound good? Awesome, let's dive in further.

Ruby on Rails

Let's assume you're a Rubyist! I hope you are, at least. It is a stupid easy-to-use backend API. The learning curve isn't difficult at all. Especially if you're already familiar with MVCs.

To set up JWT Web Tokens, you'll want to add gem 'jwt' to your Rails dependencies and run bundle install.

Now, let's learn how to use this gem!

`application_controller.rb`:

This is what your application controller should look like. Pay close attention to the notes as I've explained what is happening at each method:

class ApplicationController < ActionController::API
    # Pay close attention... "authorized" is invoked first
    before_action :authorized

    # When this method encode_token is invoked later, 
    # an object is sent as the argument.
    # The method encode provided by the JWT gem will be utilized to generate a token. 
    # JWT.encode takes two arguments, the payload object and a string that represents a “secret”. 
    # The method encode_token will return the token generated by JWT.
    # To better understand how this works, look at the "authorized" method next.
    def encode_token(payload)
        JWT.encode(payload, 's3cr3t')
    end 

    def auth_header
        request.headers['Authorization'] 
        # Checking the "Authorization" key in headers
        # Ideally, a token generated by JWT in format of Bearer <token>
        # auth_header returns this
    end

    # auth_header 
    def decode_token
        if auth_header
            token = auth_header.split(' ')[1]
            # To get just the token, we will use the .split(" ")[1] method on 
            # Bearer <token> . Once the token is grabbed and assigned to the token 
            # variable, the decode method provided by JWT will be utilized.

            begin
                JWT.decode(token, 's3cr3t', true, algorithm: 'HS256')
                # JWT.decode takes in four arguments:
                # the token to decode, the secret string that was assigned when encoding, 
                # a true value, and the algorithm (‘HS256’ here). 
                # Otherwise, if there is an error, it will return nil.
            rescue JWT::DecodeError
                nil
            end
        end 
    end 

    # decoded_token is another method above being called, which calls auth_header
    def logged_in_user
        if decode_token
            user_id = decoded_token[0]['user_id']
            @user = User.find_by(id: user_id)
        end 
    end 

    # Great, now this method is checking another method above... logged_in_user;
    # true or false? (Boolean) ^
    def logged_in?
        !!logged_in_user
    end 

    # This method is invoked first, but is dependent on a chain of other methods above.
    # If a user is not logged in or a request is not sending the necessary credentials, 
    # this method will send back a JSON response, asking them to log in. To determine that 
    # information, the method logged_in? is called. Check that...
    def authorized
        render json: { message: 'Please log in'}, status: :unauthorized unless logged_in?
    end
end

Whew! That's a lot going on in there. Believe me, this is the hardest part. Read it over, code it out a few times and it will all make perfect sense. Save it in a personal repo too! This is going to be the same code snippet in any application you write with Rails for JWT Web Tokens shy of the algorithm -- that part is up to you!

Onward!

How To USE Them!

Let's go with a basic user_controller.rb.
Take a look at this code:

class UsersController < ApplicationController
    # Invoked if ANY route is accessed in the application,
    # ... but only specific to the auto_login route.
    before_action :authorized, only: [:auto_login]

    # REGISTER
    def create 
        user = User.create(user_params)
        if user.valid?
            token = encode_token({user_id: @user.id})
            render json: {user: user, token: token}
        else 
            render json: {error: "Invalid username or password"}
        end 
    end 

    # LOGGING IN
    def login
        user = User.find_by(username: params[:username])

        if user&.authenticate(params[:password])
            token = encode_token({user_id: @user.id})
            render json: {user: @user, token: token}
        else 
            render json: {error: "Invalid username or password"}
        end 
    end

    # There’s really not much going on here. The big question is where the variable user comes from?
    # Since the method, authorized, will run before auto_login, the chain of methods in the application 
    # controller will also run. One of the methods, logged_in_user, will return a global @user variable 
    # that is accessible.
    def auto_login 
        render json: @user
    end 

    private

    def user_params
        params.require(:user).permit(:username, :password, :age)
    end 
end

As you can see, we have access to the JWT methods as defined and inherited from application_controller.rb. We assign our tokens based on a user's ID. A token is issued and will belong to that user to validate any incoming requests to the API.

localStorage

When you receive the response from a server via fetch or axios (whichever one you use), the JWT Web Token will come with it. locaStorage allows us to store this information accessible only to your machine/browser. Since this information isn't available anywhere else AND it persists all data even when the browser is fully closed, it's a great place to store a user's information to keep them authenticated.

Let's assume you just received your JWT token, and it is accessible via data.jwt. We can store this information like so:

localStorage.setItem('token', data.jwt)

And to access this token, we can use:

localStorage.getItem('token')

How you use this information is dependent on what library/framework you're using on the frontend. I use React, but explaining client storage in React is a whole blog post of its own...

Conclusion

JWT Web Tokens are a great way to make your applications more secure. There are better ways to work with JWT Tokens. In fact, here is an article that you should follow once you've gotten comfortable with how JWT Web Tokens work. localStorage is okay when it comes to React since we are passing data in a slightly different way across the application, but not all tools are created equal! The stronger your security, the better.

Happy coding, y'all!

Express RESTful Routing

Matthew Palmer — Mon, 04 Jan 2021 20:21:41 +0000

Introduction

Previously, I wrote a blog about how to get started with the Express-Generator. If you're trying to get set up in Express, you can find my tutorial here. In this blog, we're going to piggyback off my last Express blog and come to understand how the routing works.

Resources

I highly recommend that you download The Postman App. It's really great for testing HTTP requests without building testing forms and populating your database with faux data. (i.e. my_user_test@email.com + somepassword1234) Best part is, it works with any library/framework. It tests those HTTP requests while totally language agnostic to the technology handling the logic.

HTTP Requests

If you've ever handled requests before, you're familiar with the basic requests such as GET, POST, PUT, and DELETE.

HTTP Requests	Example	Meaning
GET	/posts	Meant to `GET` or show a user's post
POST	/posts	Meant to `POST` information to a database. In this case, creating a new post
PUT	/posts/:id/edit	Meant to `PUT`, or update information. In this case, updating a user's post by the ID in a database.
DELETE	/posts/:id	Meant to `DELETE` information in a database. In this case, deleting a user's post.

There are a total of 7 HTTP Requests, GET, POST, PUT, HEAD, DELETE, PATCH and OPTIONS. We will only be covering four of them.

Routes

Under your routes, create a file posts.js. Populate it with this code:

const express = require('express');
const router = express.Router();

/* GET posts index /posts */
router.get('/', (req, res, next) => {
  res.send('INDEX /posts');
});

/* GET posts new /posts/new */
router.get('/new', (req, res, next) => {
  res.send('NEW /posts/new');
});

/* POST posts create /posts */
router.post('/', (req, res, next) => {
  res.send('CREATE /posts');
});

/* GET posts show /posts/:id */
router.get('/:id', (req, res, next) => {
  res.send('SHOW /posts/:id');
});

/* GET posts edit /posts/:id/edit */
router.get('/:id/edit', (req, res, next) => {
  res.send('EDIT /posts/:id/edit');
});

/* PUT posts update /posts/:id */
router.put('/:id', (req, res, next) => {
  res.send('UPDATE /posts/:id');
});

/* DELETE posts destroy /posts/:id */
router.delete('/:id', (req, res, next) => {
  res.send('DELETE /posts/:id');
});


module.exports = router;

Now, inside of app.js, apply this line between lines 5 and 11:

const posts = require('./routes/posts');

And then this line between lines 21 and 27:

app.use('/posts', posts);

This is where The Postman App will come in handy. If you came from my first blog covering the setup of this application, you can start up your server by typing nodemon into your terminal. Using The Postman App, we can begin to test each route to be sure they are working correctly. Your response from each route will be exactly what is inside of res.send('string-information-here') with each route/HTTP request delivering their own response.

Is this the right setup for all route files?

You might think so at first, but it's important to understand that not everything in a database necessarily needs a particular action. One example would be when you're writing a review. Does it make sense to create an entire route just for a review form?

Doesn't it make better sense to attach that form in the same route as a user's post you might be viewing? Depending on the type of application you've got, you might not even want a user to delete their own review (for whatever reason). Point is, the type of routing you set up is highly dependent on the desired behavior of your application. There is no amount of information I could write here that would solidify these concepts better than if you were to write up your own code and practice narrow use cases.

Conclusion

RESTful Routing follows roughly the same pattern when it comes to MVC frameworks. Coming from a Ruby on Rails background, Express seems to be no exception. Understanding the MVC architecture is paramount as a transferrable skill. Stay tuned, because I will be continuing to write more blogs about Express in the near future. 😉

Please leave a comment if you have any questions! I'll be happy to answer.

Follow Me!

LinkedIn/MatthewPalmer9
Github/MatthewPalmer9
Twitter @MattPDev

Getting Started with Express-Generator (Express/Node.js)

Matthew Palmer — Tue, 29 Dec 2020 21:58:33 +0000

Introduction

Hi there! 👋 Welcome to my tutorial for setting up a new Express application. This isn't a tutorial for how to use it, but I'll cover getting yourself set up including ES6+ revisions. (I'll be writing future tutorials moving forward on how to use Express)

Let's get started

Step 1 - Installing the Generator

Assuming you already have Node.js installed, you will want to open your IDE of choice (I personally recommend VsCode) and type into your terminal: npm i express-generator -g

This will install the express generator on your machine.

Step 2 - Generating an Express App

Next, you'll want generate your first Express app by typing into your terminal:
express --view=ejs your-app-name

At this point, you'll want to open your project in your IDE. Alternatively, you can cd into your project. Whichever you prefer.

Once in, type into your terminal npm i or npm install to generate your package-lock.json and node_modules.

Step 3 - Fixing Declarations in App.js (Optional)

Lines 1 through 10 will be filled with declarations that are declared with var. Change all of them to const for the sake of ES6+ syntax. It doesn't matter in the beginning, but var is known to have some scope issues. Especially in much larger applications. This is optional... but highly suggested.

Step 4 - Generating `devDependencies`

There are some necessary dependencies you'll want to install. Let's walk through each one:

Type into your terminal: npm i mongoose passport
Explanation: Here we are installing two (2) dependencies: mongoose and passport. Both are used together as our MongoDB database using passport for simplified user authentication.

Type into your terminal: npm i -D locus
Explanation: The -D stands for "Development Dependencies". This will stop it from being pushed onto Heroku when we deploy in the future. locus will serve as our debugging module.

Type into your terminal: npm i -D dotenv
Explanation: Again, The -D stands for "Development Dependencies". dotenv will allow us the ability to store secret keys for APIs and any general sensitive information.

Type into your terminal: npm i -g nodemon
Explanation: nodemon is a dependency that will restart our server automatically when we change any of our files. If you're familiar with React, it's similar to a Virtual DOM, except the information we change doesn't automatically show the moment we change it. It requires us to refresh the page to see these changes. The purpose is to automate restarting the server instead of having to do it ourselves every single time we change something.

From here on out, normally we would start our server with npm start. Instead, we will be able to type nodemon into the terminal which will automatically call on npm start.

Once done, run npm i one more time to make sure node_modules is fully updated.

Step 5 - Creating Controllers, Models, & Middleware Folders

Part of a MVC (Model, View, Controller) framework requires necessary files that handle the underlying logic. If you're unfamiliar with how an MVC works, here is some helpful information to bring you up to speed. To accomplish this, type into your terminal:
mkdir controllers models middleware

Step 6 - Creating `.gitignore` and `.env`

.gitignore will ignore any files specified in this folder. To generate this, type into your terminal touch .gitignore. Inside of this file, you should include this information:

.env
/node_modules

You'll notice .env is in there. Let's create this file also. In your terminal, type: touch .env to create this file. *When it comes time to use this file, we will go into depth on how it works and what the purpose is. Otherwise, you can give a quick google search get a general idea of what .env is.

Step 7 - Fire It Up

You made it! Start your application by typing nodemon into your terminal. You can navigate to http://localhost:3000/ in your browser to verify everything worked.

Conclusion

Express / MongoDB are a great alternative to building a database for your applications. Personally, I come from a background of using Ruby on Rails as a backend API. As I learn, I will be sharing lessons in future blogs like this one! Once you're set up, you can follow along and grow with me. :) Hope to see you again soon!

Drop a comment if you have any questions. I'll be happy to answer!

DEV Community: Matthew Palmer

Introduction to SASS

Introduction

Installation

Step 1:

Step 2:

Setup

Working with Sass

Sass Variables

Sass Nesting

Imports

Sass Mixins

@mixin Variables

Conclusion

IF nothing ELSE, ternary...

Introduction

The Ternary Operator

Conclusion

React Calculator (Oh god...)

Introduction

Operators & Parenthesis

Operators (+, -, *, /)

Conclusion

React + Tailwind

Introduction

Installing Tailwind

Step 1: Dependency

Step 2: tailwind.css

Step 3: Scripts

Step 4: Making it accessible

Conclusion

Rails - find VS find_by

Introduction

What is find_by?

What is find?

Ever heard of where?

Conclusion

componentDidMount() VS useEffect()

Introduction

React

Conditional rendering

When both go wrong...

DIY Function APIs

Introduction

The Problem

What is a function API?

componentWillUpdate() and Function APIs

Conclusion

React useState State Hook

Introduction

At A Glance

How useState Is Applied

Conclusion

Let's Talk Functional Components & Hooks

Introduction

The useHistory Hook

How do we even USE useHistory?

What is a Functional Component?

Conclusion

localStorage with JWT Web Tokens

Introduction

What are JWT Web Tokens?

Ruby on Rails

application_controller.rb:

How To USE Them!

localStorage

Conclusion

Express RESTful Routing

Introduction

Resources

HTTP Requests

Routes

Is this the right setup for all route files?

Conclusion

Follow Me!

Getting Started with Express-Generator (Express/Node.js)

Introduction

Let's get started

Step 1 - Installing the Generator

Step 2 - Generating an Express App

What is `find_by`?

What is `find`?

Ever heard of `where`?

`componentWillUpdate()` and Function APIs

How `useState` Is Applied

The `useHistory` Hook

How do we even USE `useHistory`?

`application_controller.rb`:

Step 4 - Generating `devDependencies`

Step 6 - Creating `.gitignore` and `.env`