Forem: Nick

Consistency

Nick — Thu, 10 Feb 2022 04:05:44 +0000

Do you ever get that thought that pops in your head like, "I should really start doing / should do [action]..."?

That's definitely normal so don't worry. Well I like to believe it since I definitely get that thought!

The point of this article for me: simply to post.

I haven't done that in a long time after I was fairly consistent to start. When I started I was really focused on landing my first dev job while attending college and a code bootcamp (long story for another time) right about a year and a half ago.

So here I am. Posting something. I promise it'll be better next time but to at least put a lil something out there.

What tool, system, approach, reward, punishment or combination do you use to maintain consistency?

As a note that consistency is very subjective and could pertain to whatever you want - as long as you do it habitually.

How To Deploy a Full-Stack MERN App with Heroku/Netlify

Nick — Sat, 29 Aug 2020 19:35:39 +0000

This post is intended to be a guide for those that want to deploy a full-stack MERN app. It will be very specific on steps so it's a bit of a read, however, it will ensure there is minimal to no confusion on how to get from point A to point B.

Feel free to hop around if you've got some of these steps done, know how to do them already, what have you.

If this is your first time don't intimidate yourself! Just read and complete each step one at a time.

NOTE: This guide is based on my specific project structure and this works well for it. There are definitely other ways to deploy and other ways people prefer to have their project structured.

Let's get started!

Project Context

So you've got a cool project you'd like to show off to the world, how do we deploy a full-stack MERN app?

Let's first get some basics out of the way and context on how I did this: my project structure, basic configuration, and why I chose this way of deployment.

What is MERN?

MERN stands for MongoDB - Express - React - Node.

MongoDB for the database
Node & Express for the server-side
React for the client-side

There's also the MEAN stack, which uses Angular instead of React, and the... MEVN(?) stack... whatever, it uses Vue instead of React or Angular.

Project Structure

One thing that is definitely dev to dev, company to company, is how we structure our project as a whole. By this I mean where our directories are in relation to each other. Here is my fully collapsed root directory to show you the top-level:

Just three things:

My VS Code settings and extensions JSON files
Client-Side Code
Server-Side Code

I like this structure because to me there's a clear separation of responsibilities. It makes it easier for me to work on one or the other by just collapsing that whole folder. For instance if there's some UI feature I want to add/fix/alter then I have no reason to open my server directory.

I feel it makes it logical and simple to work with. Again, this is absolutely personal preference. This is also a big reason why this project was deployed in the way this guide will describe.

Some Options for Deployment

Credit to Dave Ceddia for putting this list together - this was found in a blog post of his.

Keep client and server together
- Your Express and React files will live on the same machine and Express will both serve your API requests and the React files as well
Put your API behind a proxy
- This will allow your Express and React files to still live on one machine but each will be served by a different server
Split client and server apart (the option for this guide)
- Host your Express API on one machine and the React App on another

Deployment is not something I have a ton of experience with so the first two options I've never attempted.

I do know that in some cases for deployment on one machine a lot of devs must nest their entire client directory inside of server. This was a big reason I went the route I did for deployment because for me I wanted to keep the structure pictured above with a clear separation of client-side code and server-side code.

Project Configuration

The base of the project I deployed was the Create-React-App, which comes with a webpack.config.js and other basic configurations out of the box, for the front-end.

I also used Webpack for the server directory as well to allow all those beautiful imports and exports to work for me and allow me to separate responsibilities on the server-side.

Here's a shot of the client and server directories expanded just to show you how I have it setup. There's only a couple things that will need to be there for this project structure to work which I'll point out.

Each directory, client and server, needs:

.gitignore
- To ignore the files and directories we don't want stored in our repo
package.json
- To specify our separate dependencies and devDependencies
webpack.config.js
- The client doesn't have one because Create-React-App again provides one out of the box so I didn't need to specify it there

You may have noticed I have a yarn.lock inside client and a package-lock.json inside server. I intentionally use yarn for client-side and npm for server-side because it helps me just keep those separate in my mind. I know if I'm using yarn then I'm in client and if I'm using npm I'm in server. Once again just a personal preference - you could use yarn or npm for both and have no issues.

You may have also noticed the Procfile which we'll get to later in the guide. As a teaser this will be needed by Heroku to deploy our server code which is why it lives inside of server.

Now that we have some context on how my project is setup let's talk about the actual process of deploying.

Deployment Process

What we're going to do specifically is host our server code on Heroku and our client code on Netlify. So our React App hosted on Netlify will make API requests to our Express API hosted on Heroku.

This will assume that you have both client and server running correctly and that you have already connected your app to a hosted database on MongoDB.

Steps

Create a Netlify account or sign in if you have one
Create a Heroku account or sign in if you have one
Install the Heroku CLI
- There is instructions on how to do this for both Mac and Windows in this linked article
Go to your terminal and type heroku login
- This will prompt you to press any key, once you do it will take you to your browser where you will just need to click 'Log In'.
- Once this is successful you can close that browser window and navigate to your text editor now with your project open
Create a file named Procfile, no file extension, in /server directory.
- Include this text and this text only in the Procfile
  - web: node dist/main.js
- This tells Heroku what to do after building our app - which specifically is to run our bundled file from webpack with all of our server logic inside it
- If we didn't include this it would likely build just fine but never actually start our server
Now we must add to our server/package.json the following block:
- You can more than likely add this anywhere (not nested in any other property) but I added it right below the "main" property near the top in the server/package.json.
- Recommended to check your node and npm versions first to know which versions to put in this next block. While it likely won't break your app with a slightly different version it is safer to specify the versions you used in development to prevent unexpected behavior.
- node -v or node --version to check your Node version
- npm -v or npm --version to check your npm version
- Add those versions that return to this engines property if they're different than mine.
- I used "14.x" for node to say, "As long as the major version of Node is 14 then use the latest minor version. Major version releases are when they're likely to be breaking changes which we want to avoid. ```jsx
"engines": {
"node": "14.x",
"npm": "6.14.7"
},


7. We need to allow access to your MongoDB database now from a new IP address. For simplicity, I added all IP addresses to be allowed.
    - **BIG NOTE**: In a production app **_you do not want to allow all IP addresses to access your database_**! You will want to find the specific IP address that hosts your server-side and add just that one as allowed.
    - The app I deployed does not contain any sensitive information. It's just a simple card game so no need for me to be super secure. _Once more_, do not do this for a real production app or even a side project that may contain sensitive information.
        1. Go to the [MongoDB Website](https://www.mongodb.com/) and sign in
        2. Navigate to the Project you're deploying using the dropdown on the top left
        ![MongoDB project drop down menu](https://dev-to-uploads.s3.amazonaws.com/i/mioopez440kdf4lbaxen.png)
        3. Then click the `Network Access` tab on the left side bar
        ![MongoDB Network Access Tab](https://dev-to-uploads.s3.amazonaws.com/i/xnosrkijcoy4o6rt259b.png)
        4. Click the green button on the right of the screen that says `Add IP Address`
        ![MongoDB Add IP address button](https://dev-to-uploads.s3.amazonaws.com/i/i4wg95qv9jpuzec054hu.png)
        5. A modal will popup. Click the button that says `Allow Access from Anywhere`. This will place `0.0.0.0/0` in the `Whitelist Entry` input. Then click `Confirm`.
        ![MongoDB Add IP address modal](https://dev-to-uploads.s3.amazonaws.com/i/k7rniqtjzn2ulf4wqrdy.png)

8. In development I had the express server listen to `localhost:5000` to run there and my react app ran on port `3000`. We must change what this Express server will listen for to `app.listen(process.env.PORT || 5000)`
    - So this will tell the server to listen to the `.env` environment variable `PORT` which **_we should not have set in our own_** `.env` _file_. OR it will listen to port 5000.
    - The `process.env.PORT` will be set by Heroku's `.env` - they essentially will tell our server which port to listen to.
    - If there is no such `process.env.PORT`, in other words there is no `.env` file that has been configured, then it will default to `5000`. This will allow us to keep that code in *and* be able to run it in our local development environment on port `5000` because we *do not* have a `.env` variable `PORT`.
    ```js


    // server.js

    /*
      Other code...
    */

    app.listen(process.env.PORT || 3000);

---

**Ensure in your terminal that you are inside the _root_ of the project you are deploying for these next two steps**

---

Now back inside your Terminal the next command we type is heroku git:remote -a <project-name>. Replace <project-name> with really whatever name you want - I recommend the name of your project to keep it simple. So for example it will look like heroku git:remote -a my-project.
- This is going to create a remote connection with Heroku specifically and also create a branch on that remote for you and your app name will be the name you provided, such as my-project above. Next we're going to actually push our server code to that remote Heroku branch. ```
heroku git:remote -a my-project


10. The command we need to push our `server` code specifically, because we have the separation of `client` and `server` in our project structure, is `git subtree push --prefix server heroku master`
    - This is telling git to push a subtree, or in other words a *subdirectory*, from our current git repo. The `--prefix` flag comes before that subdirectory that we want to push, in our case it is `server`. And lastly we're telling it to push to the remote `heroku` our `master` branch.
    ```


    git subtree push --prefix server heroku master

---

**IF you want to test and ensure that you've deployed your server to Heroku just add in a test route in your `server.js` like:** 
```js

app.get('/', (req, res) => { res.send('Hello from Express!')

    You can view your app by:
        - Copy and pasting the url that will appear in your Terminal after successfully pushing your code to the remote Heroku branch
        - Navigating to your project on [the Heroku website](http://heroku.com) and there will be a button that says 'View App' - click it and it will take you there
    - If you see the 'Hello from Express!' (or whatever test message you used) then that means your server is running correctly

    ---

11. Now for our MongoDB connection to work we must define an environment variable for Heroku to store our MongoDB connection string. 
    > We want to keep our connection string secret as we don't want anybody able to connect to our database and change, delete, add things etc. 
    > In our local build the connection string, is stored in our `.env` file inside of `/server`. I named by connection string `MONGODB_URI`. You can do this next step on the Heroku CLI or on the Heroku website. 
    > I recommend the website it's more straightforward and you don't have to worry about escaping special characters. I'm going to describe the next steps going through the website.
    - Navigate to your dashboard on Heroku
    - Click on your project name that will be present from our previous steps where we created our remote branch and pushed the code
    - Navigate to the Settings tab near the top
    - The second section is 'Config Vars' - click on 'Reveal Config Vars'
    - You'll see two inputs:
        - One is the name of your environment variable - name this **whatever you have it named in your local build**. For me that is `MONGODB_URI`.
        - Second is the value - paste your whole connection string here that you should copy from your `.env` file directly to avoid any typos.
    - Then just click 'Add' and our MongoDB connection environment variable is set.
    ![Heroku site config vars](https://dev-to-uploads.s3.amazonaws.com/i/7ewhhh5fybrk94691c6i.png)

    ---

    Our `server` code is officially deployed and configured correctly. Now onto the `client` code with Netlify.

    ---

12. Next is to deploy the front-end React code in `/client` to Netlify. Login to Netlify if you haven't already, the default tab should be `Sites` or just navigate to that tab.
    - Click the button that says `New site from Git`
    ![Netlify new site from git button](https://dev-to-uploads.s3.amazonaws.com/i/y01zt0d6tout6tvt3757.png)
    - Click the `Github` (or `GitLab` / `BitBucket` if that's where your repo is hosted) button below `Continuous Deployment`
    ![Netlify new site continuous deployment provider](https://dev-to-uploads.s3.amazonaws.com/i/egvtiqb6tc31p36ao838.png)
    - There will be a search bar that says `Search Repos` - type in the name of your project repo here to find it then click the line that has the repo you're looking for
    ![Netlify find repo for new site](https://dev-to-uploads.s3.amazonaws.com/i/ruf2nbhjpasof8z5ayv6.png)
    - Click `Deploy Site`. 
    ![Netlify new site deploy button](https://dev-to-uploads.s3.amazonaws.com/i/3kcvihxjge4zze3x1prn.png)
    - Once that's done it will take you to a page that shows a box near the top with your auto-generated site name and your site url right under it. In that box click `Site Settings`.
    ![Netlify post deploy screen](https://dev-to-uploads.s3.amazonaws.com/i/kt8un31fsx5ljswffwo1.png)
    - First you can change your site name here if you'd like by clicking the `Change site name` button on that first page. Do that if you'd like.
    ![Netlify change site name button](https://dev-to-uploads.s3.amazonaws.com/i/ze54wf50bk7vv9cz6nwm.png)
    - Now on the left menu bar click on the tab that says `Build & Deploy`.
    ![Netlify sidebar](https://dev-to-uploads.s3.amazonaws.com/i/bbjpw5oqo41pr4x5rcen.png)
    - Click the `Edit Settings`
    ![Netlify edit site settings button](https://dev-to-uploads.s3.amazonaws.com/i/os7b2tio2luqtew0azkn.png)
    - Change your `Base directory` to `client`, change your `Build command` to `yarn build`, and change your `Publish directory` to `client/build`. Then click the `Save` button on the bottom left.
    ![Netlify edit site build settings form](https://dev-to-uploads.s3.amazonaws.com/i/t8d1x1jsckuk24v5tfns.png)
    To ensure this all redeploys after we change these settings I like to explicity trigger a redeploy.
    - Near the top in the tabs located right under your team name and site name click on `Deploys`
    ![Netlify deploys tab](https://dev-to-uploads.s3.amazonaws.com/i/31mwopk5aw35ybs80p3x.png)
    - Then click the `Trigger deploy` button which has a drop down with two options. I always use `clear cache and deploy site` to ensure a fresh build that has all changes I've made.
    ![Netlify deploys tab](https://dev-to-uploads.s3.amazonaws.com/i/o05ey38l34lsdu80dhm6.png)

13. **LASTLY** after we deploy our front-end React code we must ensure _any requests_ we're sending from the client-side is changed to use our Heroku URL now instead of localhost.
    - In my structure the requests were being made from `client/api/index.js` so navigate to that file and *any request that contains* `http://localhost:5000` must be replaced by your Heroku URL.
    ```js


    // Before
    const res = await fetch('http://localhost:5000/scores/'

    // After
    const res = await fetch('https://my-project.herokuapp.com/scores/')

    // 'my-project' in the URL will either be the auto-generated
    // name from Netlify or if you changed the name it will
    // be the name you gave it

Ensure that you push these changes up to GitHub. Netlify will trigger a redeploy when they detect changes to your master branch. So for this to work you must make those changes apparent to Netlify essentially.

Now any request, instead of going to your local server you've ran while developing, will go to the hosted server you just deployed to Heroku with all of your Express Routes still intact and functioning properly.

You did it!

It's undoubtedly a long process to get this done. But the important thing is that it can be done!

It's awesome to see the things we build on our local machine in development. After this though you can send a live link to your friends, colleagues, etc. for them to check it out!

This is awesome to have a live example as well for anyone looking for a job. Being able to not only have a link on your Resume or Portfolio site to the code on GitHub but for recruiters, managers, whoever to be able to see the project in action is huge!

Let me know in the comments...

... how you like to deploy! Link me an article, give me a brief overview, or whatever you want. I'd love to hear of the other ways devs get their projects out there for the world to see and enjoy!

Connect NodeJS and MongoDB

Nick — Mon, 24 Aug 2020 14:26:29 +0000

Getting into full-stack development requires that we're able to work with server-side code and databases. If you're working in JavaScript you'll be using Node most likely and a popular NoSQL database MongoDB.

This article will assume you've got the basics of each already. The main topic here is how we get Node and Mongo to talk to each other.

Step 1: Visit MongoDB's website

You should either sign in or register as a new user. Simple first steps we're already gaining momentum.

Step 2: Create and Connect to a Cluster

If you do not have a Cluster yet on the site you will need to create one. It's been a while since I had zero Clusters so I'm not positive but I think it will automatically prompt you to create one.

If not, no worries, you'll see in the picture below somewhere on your screen there should be a green button that says 'Create a New Cluster'. My advice, as I've not toyed with any of the settings nor want to pay for a Cluster, just keep the default settings and make sure to create a free Cluster.

Now that you have a Cluster, or if you had one already, your screen should like like the picture above. Next you'll need to click the little CONNECT button below your Cluster name. And it will show you this screen below.

Click on the middle option that says Connect your Application.

Alright we're almost done on the website. Ensure you do Step 1 of this Connect Popup - Select your driver (which is probably Node if you're reading this) and make sure the Version is appropriate. Since we're on Node 14 I would assume you're all safe in keeping the 3.6 or later option selected.

Then just click the Copy button to copy that long string which is how your application will actually gain access to your database. You will need to replace <password> with your actual password and <database> with your actual database name. Potentially, you may have to replace <username> but normally it auto-inserts that for me before I even copy the string.

Step 3: Setup a MongoClient

Now we must go into your application code. Wherever your server code lives is now going to need a Client to create the connection between Node and Mongo. Here's a simple representation of my project directories and where the code I'm going to show lives.

-client-> (front-end code)
-server
  |__db
  |  |_client.js
  |  |_index.js
  |
  |__server.js
  |__.env

First up let's look at client.js because that's the first part we need to establish our connection.

import dotenv from 'dotenv';
import { MongoClient } from 'mongodb';

dotenv.config();

const client = new MongoClient(
  process.env.MONGODB_URI,
  {
    useUnifiedTopology: true,
  },
);

// Close the connection after the server is shut down
(async () => {
  await client.connect();

  // 'CTRL + C' -> 'SIGINT' means signal interrupt i.e. server shut down
  process.on('SIGINT', () => {
    client.close().then(() => {
      console.info('SIGINT received: DB connection is closing');

      // Avoid plugging up ports - ensures all processes are stopped
      process.exit(0);
    });
  });
})();

export default client;

Alright there's a bit going on there so let's look at it in chunks.

So first off we have some imports. The dotenv import is only to store the copied string from the last step and use it. That long string we copied from Mongo's website on our Cluster is stored in the .env you saw in my directory structure. The dotenv.config() simply allows me to use those environment variables I've declared in .env in this file here.

The process.env.MONGODB_URI could be replaced by the actual string we copied. So if you don't want to setup a .env you don't have to.

Now the MongoClient import is fairly self-explanatory on what it's role is - it's how we will establish the connection. The const client = part is where we declare a new MongoClient and pass some arguments.

First is our connection string (again you could just paste the string here if you wanted)
An object to pass additional options - here we just pass useUnifiedTopology: true

import dotenv from 'dotenv';
import { MongoClient } from 'mongodb';

dotenv.config();

const client = new MongoClient(
  process.env.MONGODB_URI,
  {
    useUnifiedTopology: true,
  },
);

To be honest, I'm not 100% on why useUnifiedTopology: true helps us. Here's Mongo's Reference Page on it. I read through and in the most basic sense it seems like a step towards making future updates easier. I could totally be wrong on that though.

Let me know in the comments what your understanding of useUnifiedTopology is!

Alright, next chunk of code.

Obviously we export the client we've created so lets just get that bit out of the way.

Now the bulk of this code is that Asynchronous IIFE. It's purpose is to establish our connection and then when our server shuts down to close that connection. The comments in there already should help clarify certain parts.

We connect by awaiting the method available to us from our MongoClient object => connect(). Pretty simple.
Then once we get the SIGINT from the server we close that database connection. Because our parents taught us to clean up after ourselves and it's not just for our rooms!

// Close the connection after the server is shut down
(async () => {
  await client.connect();

  // 'CTRL + C' -> 'SIGINT' means signal interrupt i.e. server shut down
  process.on('SIGINT', () => {
    client.close().then(() => {
      console.info('SIGINT received: DB connection is closing');

      // Avoid plugging up ports - ensures all processes are stopped
      process.exit(0);
    });
  });
})();

export default client;

Step 4: Use your `client`

Now how do we use this client that has connected for us? Here's one method out of my db/index.js.

import client from './client';

// GOOD
export const addNewUser = async (newUser) => {
  try {
    return await client.db('throwaway').collection('users').insertOne(newUser);
  } catch (err) {
    throw new Error(err);
  }
};

Import our client from our file
Then simply use it as such in the try/catch block
- client
- .db(<NAME OF YOUR DATABASE>)
- .collection(<NAME OF YOUR COLLECTION>)
- .<METHOD YOU NEED>

Some notes here: newUser is an object passed in from the client-side request. And since it is an object already I can pass it directly into the insertOne method.

Moving Forward

In my experience MongoDB can be pretty particular about how things are formatted, or passed in especially to those CRUD methods like insertOne(), find(0), findOneAndUpdate().

This is important to making sure the data you're trying to read, write, delete, or update is actually having their operation complete properly.

Get Some Practice

I recommend instead of worrying about coming up with a project that will need data and coming up with how that data should look - just use MongoDB's sample data.

Once you create a cluster you can essentially download some sample Collections.

Do that, spin up a quick project structure like an index.html, barebones CSS and the server-side code you've seen in this article. The play around with how to pass data in correctly, get your client-side requests to the server-side (which is a whole different article), even just define a const in your server code and pass it to the DB method and see if it updates.

Time on task will help more than most things!

React Lifecycle Methods - The Basics

Nick — Mon, 17 Aug 2020 15:14:41 +0000

If you're using React then you're likely using Components. Why else would you be using React if you weren't, right? If you're using Components then you'll end up needing at least a little knowledge of how the Component Lifecycle operates.

The Basics

In the React Docs on Components they do a great job of laying it all out. I definitely recommend reading it over. This article should provide you a quick overview of the Lifecycle, it's most commonly used methods, and how some of the common Hooks fit into that lifecycle.

So first, as React was initially based around, and still probably most commonly used at least for now, classes. The Lifecycle Methods are methods of React Classes.

We can break these methods up into three categories:

Mounting
Updating
Unmounting

Updating seems self-explanatory, but what does it mean to mount or unmount?

Mounting

When a Component has mounted that means that a couple things have already taken place.

That Component's constructor() has been called and finished
The Component's render() has ran for the first time

At this point in time specifically after this Component for the first time has been initialized with its constructor() and it's first render() called it has mounted.

It is, in simplest terms, the first time that a Component renders to the screen. This is where the componentDidMount() lifecycle method comes in.

`componentDidMount()`

This method is where, as a developer you'd like to make an API call, an initial database query, basically anything that can take some time fetching from a remote source. The Component has already rendered so the User won't be staring at a blank screen while waiting for the data to come back because these are asynchronous tasks.

You can also setState() inside of this method and if it's not dependent on an asynchronous task it will fire another render(). The good thing is with a synchronous task here the User will not see the intermediary state.

constructor()
render()
componentDidMount()
render() (If the state was changed in componentDidMount())

Updating

This one again is pretty self-explanatory. This is when a Componenet has updated. To be more specific, whenever we pass in new props to a Component or if the state within that component has changed the Component has updated.

So what happens on an update? Well, a render() of course! Followed up by our next lifecycle method componentDidUpdate().

Now there is a less used method shouldComponentUpdate(), but take a look at the React Docs on Components if you want to know more about the usage of that.

`componentDidUpdate()`

This'll be a quick one. We already know that new props or setState() causes a render() and then componentDidUpdate() will fire.

What do we use it for though?

It's almost exactly the same use as componentDidMount(). Network requests are a big use case for this method. You can just the same call setState() inside this lifecycle method.

One catch to using setState() inside componentDidUpdate() is to be wary of the infinite loop. If you must use setState() inside componenetDidUpdate() then you must also compare props with previous props. Doing this will prevent that infinite loop.

To clarify here's an example straight from the Docs that we'll add one line to and break down a little bit.

We can tell there's a method on this class Component called fetchData() that clearly takes a userID. We see that the userID is coming from props. Okay, nothing crazy.

componentDidUpdate(prevProps) {
  if (this.props.userID !== prevProps.userID) {
    const dataObject = this.fetchData(this.props.userID);
    this.setState(dataObject)
  }
}

To understand where the problem lies lets layout the lifecycle method calls.

Lets say this component has already went through

constructor()
render()
componentDidMount()

And now in our program the user has performed an action that changes our props. Lets say they entered their ID into an input and now we pass that down as a prop to this Component.

User enters ID into input on a form and submits
The props of this component change
- Which will trigger a componentDidUpdate()
componentDidUpdate()
- Which has a setState()
The state of this component changes
- Which will trigger a componentDidUpdate()

At this moment if we do not compare the Previous Props to the current Props and ensure that they are different we will fall into that infinite loop because state is set inside the update.

Props change
componentDidUpdate()
setState()
componentDidUpdate()
setState()
componentDidUpdate()
etc. etc. etc. NOOoooooo, why me!?!

Unmounting

This will also be quick. The only time this is ran is when the Component is being taken out of the DOM tree altogether and destroyed. And it has only one method: componentWillUnmount().

Now this is one personally I haven't used yet. The Docs put it pretty succinctly and in a way that I understand but haven't in my little React experience needed quite yet.

Perform any necessary cleanup in this method, such as invalidating timers, canceling network requests, or cleaning up any subscriptions that were created in componentDidMount().

Don't bother using setState() in this method as the Component is removed and destroyed immediately after whatever functionality you have inside this function.

No amount of standing outside it's house with a boombox jamming "In Your Eyes" by Peter Gabriel will bring it back.

Definitely still go to the React Docs on Components and read up. They have great examples, they show the less used (but still useful) lifecycle methods, and they also include the Error Boundary ones which I did not for simplicity.

My biggest recommendation for understanding these methods and their timing is to just

use create-react-app to make a project
create a Component under App and a child under that as well
- Maybe something like App > Parent > Child
- Literally just call them that for clarity
In each component call these methods with a simple console.log and the method name
Then change some props, change some state, etc. and see the order in which these methods fire!

This was absolutely the biggest help for me to get a better grasp on these React Lifecycle Methods. Oh, and did I mention to read the React Docs on Components?

`useEffect()` and `async`

Nick — Mon, 10 Aug 2020 14:03:53 +0000

If you've learned the traditional class-based React Components and you're now trying to move into Hooks there's a few things along the way that'll throw you for a loop.

One such thing that took a little digging for me is the combination of useEffect() - essentially the replacement for componentDidMount, componentDidUpdate, and componentWillUnmount - and async/await.

The Situation

Common scenario: Our app loads, we get something on the screen AND THEN we want to fetch some sort of data. We don't want to block the User from moving on or make them stare at a blank screen because our API call is taking longer than expected.

`componentDidMount`

This is the method in which we remedied this problem if using React Class-based Components. It ensures that the actual Component is inserted into the DOM tree first and then render() is called.

If we don't need an API request to be made then the Component will simply render to the screen. If we do need to make an API request we should do that inside of componentDidMount(). In addition if upon receiving the API response we must update, or setState(), then that will actually trigger a second render.

Then the calls will look like this:

componentDidMount()
render()
setState() [from inside componentDidMount()]
render()

Even though there is a second render, the React Docs state that the user will not see the intermediate state. So no weird flickering UI - that's good for us! However, the Docs also say to be cautious as this way could lead to performance issues.

More specifically, any DOM node that needs insertion into the tree belongs in this spot, componentDidMount(). If you can React recommends that initialization of state be done in the constructor() instead of here. Obviously, that isn't always viable but it is what they recommend.

// src/api/index.js 
export default {
  async index() {
    const res = await fetch('https://my-json-server.typicode.com/Claim-Academy-JS/products/products')

    return await res.json()
  }
}

/* ------------------ */
import api from 'api'

async componentDidMount() {
  const products = await api.index()
  this.setState({ filteredProducts: products, products })
}

This code shows the fetch call being made inside componentDidMount() and in this case for my project I needed this setup. These products were to be inserted into the DOM tree so I make the fetch call and set my state. Of course async is on both componentDidMount() and my exported object's index() method. Then inside both of those we await the results.

`useEffect()`

Now with Hooks, more specifically useEffect() there's a couple things we need to be aware of. First we must understand that useEffect() takes two arguments.

First Argument

Callback function

Second Argument

Property to watch for a change -> then fire the provided callback

So as per usual, a callback is needed - no surprise there. The second parameter can cause some problems if we forget to specify it. If there is no second argument provided the useEffect() will fire on every update no matter what is being updated. Even further, if there's a setState() or a useState() setter being used inside - useEffect() will go into an infinite loop.

Let's take a look at an equivalent code to the previous example just instead utilizing useEffect():

  useEffect(() => {
    (async () => {
      const products = await api.index()
      setFilteredProducts(products)
      setProducts(products)
    })()
  }, [])

This time you see there is an Immediately Invoked Function Expression, or IIFE, inside. We could just as well name that function and then specifically invoke it inside too.

  useEffect(() => {
    const fetchProducts = async () => {
      const products = await api.index()
      setFilteredProducts(products)
      setProducts(products)
    }
    fetchProducts()
  }, [])

Also take note, we are actually providing a callback to useEffect() and within that callback we must define another function and invoke it. That's due to a fetch call returning a Promise. So essentially useEffect() itself isn't responsible for that so our defined function will handle it.

Lastly that second argument is present to ensure this useEffect() only runs at a specific time.

There we provided [] as the second argument. This is telling useEffect() "Hey, I only want you to run your callback when this Component mounts for the first time and that's it." By using [] we tell useEffect() that there are no properties we want you to watch and then run your callback when they change. Just run once.

There's a difference too between [] as a second argument and no second argument. As mentioned before without a second argument that useEffect() will think it should run when the component mounts and then on every single update after regardless of what piece of state changes.

If we wanted a function to run each time a specific piece of state changes you would simply put it inside the brackets like so [somePropertyNameHere].

Article Will Unmount

It took a little digging to find the way to combine useEffect() and async functions. It was definitely surprising the the React Docs has no examples of this situation at all that I could find. I referenced a few different 3rd party articles explaining this to be sure I was on the right path by what all of them said. Robin Wieruch wrote about this; it was the first one and one of the better articles I found on this topic.

Definitely happy to figure it out because even though this was a weird one to figure out - I still like Hooks more!

Starting with React Hooks

Nick — Mon, 03 Aug 2020 15:22:30 +0000

For just over a year now we've had access to this shiny new feature React Hooks. I'm sure most of us have at least heard of it.

For me I didn't know what it truly meant or how it compared to what was being done in React prior, honestly. So recently starting to work with React I've been learning about the Class-based approach as well as Hooks.

What Are Hooks?

Hooks are functions that let you “hook into” React state and lifecycle features from function components.

That is straight from ReactJS.org. Pretty simple, right? Seems so at least.

For me it was good to learn the Class-based approach first to understand where React was to move into using Hooks. It also made me appreciate Hooks that much more as I feel it's a little cleaner and more intuitive - that's personal preference though.

Class-based approach

When utilizing this approach we would define a class component that extends React.Component, that way we get access to the React lifecycle methods. This approach in itself has come a long way from the start.

Here's the traditional way we handled Class-based Components, again straight from ReactJS.org:

class Toggle extends React.Component {
  constructor(props) {
    super(props);
    this.state = {isToggleOn: true};

    // This binding is necessary to make `this` work in the callback
    this.handleClick = this.handleClick.bind(this);
  }

  handleClick() {
    this.setState(state => ({
      isToggleOn: !state.isToggleOn
    }));
  }

  render() {
    return (
      <button onClick={this.handleClick}>
        {this.state.isToggleOn ? 'ON' : 'OFF'}
      </button>
    );
  }
}

ReactDOM.render(
  <Toggle />,
  document.getElementById('root')
);

Now we can shorten that first bit where we had to call constructor(props) and super(props) and this.state = {} AND we had to bind any event handler we defined. It was just a bit cumbersome.

Here's the shorter Class-based Component syntax:

class Toggle extends React.Component {
  state = {
    isToggleOn: true
  }

  handleClick = () => {
    this.setState(state => ({
      isToggleOn: !state.isToggleOn
    }));
  }

  render() {
    return (
      <button onClick={this.handleClick}>
        {this.state.isToggleOn ? 'ON' : 'OFF'}
      </button>
    );
  }
}

ReactDOM.render(
  <Toggle />,
  document.getElementById('root')
);

A little shorter and cleaner, right? All we have to do is just define the state object, set our properties and the only other change was converting handleClick into an arrow function - that way this will still reference our component.

Side Note: Functional Components

Functional Components are in a simple explanation just function that will return some jsx. A 'dumb component' if you will. They do not need to know state and just receive props to render their jsx correctly.

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

Quite simple.

Hooks

When utilizing Hooks our Functional Components take over the role our Class-based Components had. Hooks will not work inside a class - we must use our Functional Components.

For reference in the upcoming examples here is the previous Toggle Component refactored to use React Hooks:

const Toggle = () => {
  const [isToggleOn, setIsToggleOn] = useState(true)

  const handleClick = () => {
    setIsToggleOn(!isToggleOn)
  }

  render() {
    return (
      <button onClick={handleClick}>
        {isToggleOn ? 'ON' : 'OFF'}
      </button>
    );
  }
}

ReactDOM.render(
  <Toggle />,
  document.getElementById('root')
);

Commonly Used Hooks

In the Class-based approach we would have access to certain lifecycle methods that allowed us to update our application at the right times and perform operations at the right times.

`useState()`

This Hook took over for setState() in Class-based components.

const [isToggleOn, setIsToggleOn] = useState(true)

This useState() allows us to simultaneously set the state of isToggleOn with the argument provided to the method - here that is true - as well as get back a setter to change that piece of state in the future - here it's called setIsToggleOn.

The 'set' part of that is convention to make it clear that this function will set the piece of state called isToggleOn.

Call useState() for as many pieces of state you have in different calls and you'll have setters for each piece of state. It can make it much more clear what we're trying to change.

// Class-based setState()
handleClick = () => {
    this.setState(state => ({
      isToggleOn: !state.isToggleOn
    }));
  }
// Hooks
const handleClick = () => {
    setIsToggleOn(!isToggleOn)
  }

It's shorter and arguably more intuitive than having to type out all of the Class-based way.

`useEffect()`

Now when we needed to fetch data, setup subscriptions or explicitly change DOM elements we would use the lifecycle methods componentDidMount, componentDidUpdate and componentWillMount.

With useEffect we basically have those three methods wrapped up inside of just his one. Definitely check out the docs on useEffect as it goes way more in depth and gives you context on the best practices on how to split your logic.

Here, since I'm still reading those docs and wrapping my own head around this, I'm only going to provide a simple example that involves data fetching. This example is from a small practice project I recently did:

// The 'api.index()' method used in the following block of code that makes the call for data
export default {
  async index() {
    const res = await fetch('https://my-json-server.typicode.com/Claim-Academy-JS/products/products')

    return await res.json()
  }
}

  // Class-Based
  async componentDidMount() {
    const products = await api.index()
    this.setState({ filteredProducts: products, products })
  }

  // Hooks
  useEffect(() => {
    const fetchData = async () => {
      const products = await api.index()
      setFilteredProducts(products)
      setProducts(products)
    }

    // If the data hasn't been fetched then make the api call
    if (products.length === 0)
      fetchData()
  })

So in our Class-based Components we would use componentDidMount to ensure before we made an attempt to fetch data the component itself was rendered and then we would update it on receiving our data from the server. This lifecycle method runs just once as the Component only mounts once in its lifecycle.

useEffect will run when the Component mounts, each time it updates and right before it unmounts. That is why there's a piece of logic to ensure we don't attempt to re-fetch the data each time this Component updates.

Custom Hooks

Custom Hooks are basically what they sound like - your own defined Hooks that you can design to help you with application-specific tasks or maybe tasks you've found yourself doing a bunch and could be streamlined having your own Hook for that task.

Once again, Hooks are something I've been working with just a week or so at this point. I'm not the one to tell you how to develop your own Custom Hook because I haven't tried myself yet!

The docs on Custom Hooks do a good job explaining and have a great example to show a proper use case. It made sense to me reading but I'm not going to try and rehash that here as I haven't put it in practice yet.

There Is Much More to Hooks...

... than I can tell you! I'm only beginning to scratch the surface of how to use Hooks to their full potential.

Not to mention the Custom Hooks I've yet to experiment with if you check out the Hooks API Reference you'll see even more out-of-the-box Hooks like useContext, useReducer, useLayoutEffect and more!

These examples I have were just the first Hooks I've put to use and made me see the benefit and potential of utilizing Hooks moving forward.

Callbacks vs. Promises

Nick — Mon, 27 Jul 2020 15:48:43 +0000

Basically whenever you need to get data from a server, do something with that data, maybe grab more data from another server you'll be using either callbacks or Promises.

It's a way to do something you need to do with that data once it comes back.

Callbacks

Callbacks are the parameter we use in many cases to provide functionality. A very common one is using a callback for addEventListener() when in web development.

document.querySelector('button').addEventListener('click', () => {
  // This is where your logic goes in the callback!
})

The Bad

When we end up with a ton of if else statements nested, resulting in callback hell, we're again normally fetching data or manipulating data and need to ensure each step of the way an error hasn't occurred.

This example is from callbackhell.com and shows pretty well this issue.

This is going through a directory and attempting to resize files. It's not as important to understand the code here but simply the structure.

fs.readdir(source, function (err, files) {
  if (err) {
    console.log('Error finding files: ' + err)
  } else {
    files.forEach(function (filename, fileIndex) {
      console.log(filename)
      gm(source + filename).size(function (err, values) {
        if (err) {
          console.log('Error identifying file size: ' + err)
        } else {
          console.log(filename + ' : ' + values)
          aspect = (values.width / values.height)
          widths.forEach(function (width, widthIndex) {
            height = Math.round(width / aspect)
            console.log('resizing ' + filename + 'to ' + height + 'x' + height)
            this.resize(width, height).write(dest + 'w' + width + '_' + filename, function(err) {
              if (err) console.log('Error writing file: ' + err)
            })
          }.bind(this))
        }
      })
    })
  }
})

The Pyramid of Doom makes an appearance. On the left we see the indentation gradually getting further to the right and then closing with a bunch of } and }). Easy recipe to make simple errors based on one parenthesis or curly bracket.

Each step of the way we nest another if else and there is a total of 4 callback functions nested in there.

The Good

This is the only way as JavaScript developers we were able to do these asynchronous tasks prior to Promises.

It's a good thing to know of, be able to read and understand what's happening and why. There will be code out there you may work on for a long time most likely that has this structure.

Some people prefer it and that's totally fine! We all have our own preferences as devs and if the task is completed properly there's no problem truly.

Not to mention the example above isn't written as well as it could be. Again visit callbackhell.com as it has this example and goes through steps on how to improve it while still using callbacks.

Steps such as name your functions instead of using anonymous ones, try to keep it shallow when nesting and always handle each potential error.

Remember, only you can prevent callback hell and forest fires

--callbackhell.com

Promises

The Promise in JavaScript was made official in the release of ES6. Since then they've become a widely supported and accepted feature of JavaScript.

A Promise is essentially an object that represents some asynchronous task that will eventually succeed or fail. If it 'suceeds' we say it is fulfilled and we will use the .then() method to handle success.

If a Promise fails it is said to have been rejected and we will use the .catch() method to handle that failure and error.

The Bad

Promises are meant to be a asynchronous tasks. And since JavaScript lets us pretty much willy nilly write whatever we want we can end up with some bad code.

Craig Martin here on Dev.to has written a great article on the pitfalls of Promises in JavaScript.

Definitely read that article for a much better explanation on this than I could provide you. I'll quote him directly from the Intro of his article there with his three biggest issues with Promises:

Promises have an API which encourages casually dangerous code

Promises lack a convenient API to safely work with data.

Promises co-mingle rejected promises and unintended runtime exceptions

We always have tradeoffs in writing code and a Promise is no different.

The Good

Using a Promise can result in some more succinct, clean code than nesting callbacks. Take that with a grain of salt because again we've all got our preferences and that may not be true for all!

I also believe it's easier to debug and separate concerns as we can modularize our code a little more when converting to Promises.

I took just the first part of the above callback example and converted it to return a Promise:

const readDirPromise = (source) => {
  // Return a new Promise
  return new Promise((resolve, reject) => {
    // Do the actual file system read
    fs.readdir(source, (err, files) => {
      // If there's a problem reject with error thrown
      if (err) reject(err)
      // Else we succeed and resolve with the files
      resolve(files)
    }
  })
}

readDirPromise(source)
  .then(data => {/* Do something with data */})
  .catch(err => {/* Handle error */}

This way we don't have to nest a whole lot. We place this piece of logic in a function that will either resolve and move on or reject and show us the error.

If we continued to convert that whole callback example we would simply take each part with a specific task and place that inside its own function like readDirPromise and call those in the then() statements.

readDirPromise(source)
  .then(data => {/* secondStep() */})
  .then(data => {/* thirdStep() */})
  .then(data => {/* fourthStep() */})
  .catch(err => {/* Handle error */}

Each time we chain then()s we're expecting the last step to resolve or succeed. If at any point there is an error our single catch() statement will handle it instead of having an if (err) a whole bunch. Then we can place the code for handling each type of error in just the catch().

Final Thoughts

I think Promises are great and want to do more with them. That said I worked with callbacks first and certainly have an appreciation for them. Especially in simpler tasks it might be easier just to use callbacks. Once more they're present in a lot of code because that was the way to achieve our asynchronous goals in the dark pre-ES6 days.

Having a solid understanding of the foundational pieces of JavaScript, in my mind, helps us understand and appreciate all the awesome, new features we've gotten in just the last handful of years.

JavaScript Array.flat()

Nick — Mon, 20 Jul 2020 15:29:05 +0000

Array methods in JavaScript can be super helpful. This method is no exception!

Array.flat() is a method that will in short simplify an array for you. The two big things it can do is take an array that has nested elements and return a new array with less nesting and it can remove empty array elements.

Removing nested Arrays

This is truly the biggest help of this method. The only argument that flat() takes is the depth of which you'd like to go and reduce the nesting. The default, if you provide no argument since it's optional, is flat(1) or depth 1.

Take this array for example:

const nums = [1, 2, 3, [4, 5], 6, [7, 8], 9]

We see it has two elements at indices [3] and [5] that are themselves array. What if you need the sum of these numbers? Well you could write your own function to test if the elements are arrays before adding to deal with the nesting.

Or we can use flat() and then you'd be able to use reduce() to get your sum in a much simpler way.

const nums = [1, 2, 3, [4, 5], 6, [7, 8], 9]
const flatNums = nums.flat()
console.log(flatNums) // output: [1, 2, 3, 4, 5, 6, 7, 8, 9]

Using flat() gives a simple, one-level array. In the example above we didn't pass an argument because the default is 1 and that is as far down we needed to go.

To visualize the nesting levels check this out. Each comment will state the deepest level each array has and the number of elements. Each time we nest an array we add a level to depth. Also, just like array indices - we start at 0 and can say the first level is equivalent to depth = 0.

[1, 2, 3, 4, 5] // Depth: 0 - Elements: 5
[1, 2, 3, [4, 5]] // Depth: 1 - Elements: 4
[1, 2, [3, [4, 5]]] // Depth: 2 - Elements: 3
[1, [2, [3, [4, 5]]]] // Depth: 3 - Elements: 2

Maybe a simpler example to look at is this one:

[1, 2, 3, 4, 5] // Depth: 0 - Elements: 5
[1, 2, 3, 4, [5]] // Depth: 1 - Elements: 5
[1, 2, 3, 4, [[5]]] // Depth: 2 - Elements: 5
[1, 2, 3, 4, [[[5]]]] // Depth: 3 - Elements: 5

Now lets talk more about...

Depth

Each example above on the last line reaches a depth of 3 because that is the number of additional brackets we would need to use to reach the deepest element.

For us to reach the number 5 in this array const arr = [1, 2, 3, 4, [[[5]]]] we would need to use 4 sets of brackets in our notation.

One set to access the element where the nested arrays are stored and three sets to reach the 5. That would look like this arr[4][0][0][0]. The arr[4] grabs [[[5]]] and then the next two [0] accesses the nested arrays and finally the last [0] will grab 5.

const arr = [1, 2, 3, 4, [[[5]]]] // Depth: 3

console.log(arr[4]) // output: [[[5]]]
console.log(arr[4][0]) // output: [[5]]
console.log(arr[4][0][0]) // output: [5]
console.log(arr[4][0][0][0]) // output: 5

Looks like a headache to deal with all that bracket notation, right?

That's where flat() comes to the rescue. We can take those structures and flatten them out to be a single level array and use one set of brackets to access any element we need.

IF we know the exact depth of our deepest nested array we can simply pass in the appropriate argument.

[1, 2, 3, 4, 5] // No flat() needed
[1, 2, 3, 4, [5]] // flat(1)
[1, 2, 3, 4, [[5]]] // flat(2)
[1, 2, 3, 4, [[[5]]]] // flat(3)

Each of those will return the one-level array [1, 2, 3, 4, 5].

Now what if we're not sure of the depth needed to flatten an array? What if we're receiving this data randomly? Or if we just want a way to flatten all arrays without worrying about 'what is the deepest level'?

There is a simple way to achieve that:

const arr1 = [1, 2, 3, 4, [5]]
const arr2 = [1, 2, [3, [4, 5]]]
const arr3 = [1, 2, 3, 4, [[[[[5]]]]]]
arr1.flat(Infinity) // output: [1, 2, 3, 4, 5]
arr1.flat(Infinity) // output: [1, 2, 3, 4, 5]
arr1.flat(Infinity) // output: [1, 2, 3, 4, 5]

Passing Infinity will ensure the deepest level is always reached and return a one-level array.

Removing empty elements

One neat feature, that may not be intuitive from the name and it's other main function, of flat() is it will remove any empty elements.

const arr = [1, 2, , 3, , , 4, 5]

console.log(arr.flat()) // output: [1, 2, 3, 4, 5]

This will work also if a nested array contains or is simply empty elements.

const arr = [1, [2, ], 3, [ , ], 4, 5]

console.log(arr.flat()) // output: [1, 2, 3, 4, 5]

Why should we use `flat()`?

The biggest benefit of flat() is that it normalizes our array. We can use it to ensure that our array is in an easy to use format that won't give us any weird situations.

Having data in a consistent format allows us to utilize them with more consistent results and our programs to behave as we expect. At least we hope!

Scope in JavaScript

Nick — Fri, 17 Jul 2020 16:49:10 +0000

Scope

This one is definitely important to having your code run properly or as expected. If you're accessing a variable that's in a separate closure than the one you're trying to access from you won't get the result you need.

What is Scope?

In my own simple words, scope can be thought of as a 'field of view'.

Pirate Ship Analogy

Think of an old Pirate ship. HOLD ON - just stay with me.

Let's say we have 3 Pirates named Jack, Anne and Bill.

Anne positioned on the Main Deck has a specific field of view. Jack in the brig below looking through the open grate has his own view as well. Bill way up in the Crow's Nest looking out for other ships has a different field of view.

Now we could say that Jack in the brig below has the most limited view.

Anne on the deck can see what Jack sees and even more.

Then Bill in the crow's nest can see all of what Anne and Jack can see.

Lastly, they all can see the open sea - which for our purposes will be the global scope.

Field of view: Global > Bill > Anne > Jack

Pirate Ship Scenario #1

Let's say the Captain is on the Upper Deck - which is above the Main Deck and below the Crow's Nest.

What if Jack wanted to know where the Captain of the ship was? He most certainly can't see him inside the brig - so he asks Anne.

Anne on the Main Deck can't really see the Upper Deck from her field of view. So she's not sure either.

Now they ask Bill all the way up in the Crow's Nest can see the Captain on the Upper Deck so he passes that information down to Anne and down to Jack.

Must be some nice Pirates to even pay attention to Jack in the brig... Anyway, lets see what that could look like in code.

function Bill() {
  let CaptainLocation = 'Upper Deck'

  function Anne() {
    function Jack() {
      console.log(CaptainLocation)
    }
    Jack()
  }
  Anne()
}
Bill()

Jack() is trying to log the Captain's Location but it's not within his scope or, in other words, his {}. It's not it Anne() either so that one console.log() reaches all the way up to Bill() to find the value.

Pirate Ship Scenario #2

Now if any one of our friendly Pirates wanted to know if it's storming. They could easily determine that looking to the open sea or the global scope.

let isStorming = true
function Bill() {
  console.log(isStorming)
  function Anne() {
    console.log(isStorming)
    function Jack() {
      console.log(isStorming)
    }
    Jack()
  }
  Anne()
}
Bill()

The global scope gives access to its information to all things in our code because each line of our code is enclosed inside it.

When we create closures, most commonly through declaring a function, we put a set of blinders on whatever goes inside the {}.

Now let's return to a way more basic, less ridiculous set of examples.

Some basic examples

Let's roll through a couple scenarios to see how these closures affect what our super complex variable x resolves to in each console.log().

  const x = 0
  console.log(x) // Global scope : x = 0

  function func1 () {
    const x = 5
    console.log(x) // func1() scope : x = 5
    func2()
  }

  function func2 () {
    const x = 8
    console.log(x) // func2() scope : x = 8
  }

  func1()
  /* output : 0
              5
              8
  */

This is because each console.log(x) has its own scope and as such will have a different value when accessed.

If we modify that slightly to remove the x declaration from func2() then you'll see it goes to the global scope and finds x and therefore logs 0.

  const x = 0
  console.log(x) // x = 0

  function func1 () {
    const x = 5
    console.log(x) // x = 5
    func2()
  }

  function func2 () {
    /* x no longer declared here! */
    console.log(x) // x = 0
  }
  func1()
  /* output : 0
              5
              0
  */

Why did x resolve to 0 instead of 5? func2() called func1(), right?!

Even though func2() is called inside of func1() it is not ENCLOSED by func1(). So func2() tries to find x in its own scope first, doesn't find it so it moves to its enclosing scope which is the global scope.

Now if we move the declaration of func2() inside of func1() it will go like this:

Try to find x in local scope (or func2() scope basically)
- x not found -> move up in scope
Try to find x in the enclosing scope (or func1() scope)
- x found -> x = 5

  const x = 0
  console.log(x) // Global scope : x = 0

  function func1 () {
    const x = 5
    console.log(x) // func1() scope : x = 5

    function func2 () {
      console.log(x) // func2() scope : x = 5
    }

    func2()
  }
  func1()
  /* output : 0
              5
              5
  */

Lastly, if we were to remove the x declaration from func2() then no matter if func1() is declared inside or outside of func2() we will see x = 0 because both functions do not find x in their respective scopes and must eventually move to the global scope to find an x value.

This can most definitely be a point of confusion. I know it was for me and I had to double check all of these outputs!

What I recommend, simply because it helped me become more familiar and ensure I'm getting the right value, is to do what you've seen in these examples.

console.log() the heck out of your values if something doesn't seem right or just to be safe.

console.log() is your friend! So is scope but it's that one friend who can definitely get on your nerves sometimes.

Arrow Function Expressions - The Basics

Nick — Mon, 13 Jul 2020 16:59:56 +0000

ES6, or ECMAScript 2015, brought us many great changes to the language of JavaScript. One such feature is Arrow Functions. That's what we'll dive into in this article - get to reading!

What is an Arrow Function Expression?

An Arrow Function Expression is simply a new syntax to write function expressions as we've done before. In a lot of cases it can be much shorter to write which is great. If your task requires less typing you'll get more done in the same amount of time!

Granted you understand it - which I most certainly did not in my first encounters with the mighty =>.

Here's a very basic example (which there will be more of):

/* * These are equivalent * */
// ES5
function func() {
  console.log('Function Expression example.')
}
func()
// ES6
const arrow = () => {
  console.log('Arrow Function Expression.')
}
arrow()

There are multiple aspects to the usage of Arrow Functions such as when it's best to use and not use them and some small gotchas on when they behave differently than an normal Function Expression. We won't cover them all here but we will cover some of the bigger ones.

Which is better?

Wrong question to ask. You can accomplish your task using either method. People have opinions on this subject all around - but lets face it that will never change.

However, there are certain scenarios where a strong case can be made to use or not use an Arrow Function.

When to Use

When your resulting code will be shorter and more concise
When your code becomes more readable
When you feel like it!

When not to Use

As an object method directly
When your resulting code isn't any shorter or concise
When your code can become more confusing or hard to read and understand
When you do not feel like it!

Keep in mind it largely comes down to personal preference on what you believe is more readable, more concise, less confusing, etc. As mentioned there are a couple things to be aware of when choosing which route to take.

Arrow Function: To code or not to code?

One big item to know is Arrow Functions are lexically bound. Let's take a look at a couple examples first:

// ES5
var person = {
  name: 'Foo Bar',
  logName: function logName() {
    setTimeout(function() {
      console.log(this.name)
    }.bind(this), 1000)
  }
}

In order for the logName() method to actually log out the name property we must ensure the setTimeout binds this. We see that it is chained at the end of setTimeout - if we did not do that then this would actually be undefined since the callback function of setTimeout does not have its own this. We explicitly bind it to the this of logName which is of course person.

// ES6
var person = {
  name: 'Foo Bar',
  logName: function logName() {
    setTimeout(() => {
      console.log(this.name)
    }, 1000)  // No binding of 'this'
  }
}

This time with Arrow Functions we do not have to ensure binding of this to properly log it. IN THIS SCENARIO. (Gotcha comin' up...)

The catch here is that Arrow Functions cannot be bound to a this so it will go up in scope to find the value of this in the context which it was called - AKA lexically bound.

It's not recommended to use Arrow Functions directly as object methods like the following:

var person = {
  name: 'Foo Bar',
  logName: () => {  // => instead of function expression
    setTimeout(() => {
      console.log(this.name)
    }, 1000)
  }
}

Now this.name will return undefined. It's a little confusing but a key thing to remember is that again an Arrow Function will not have a this attached to itself. I like to think of Arrow Functions just passing the buck.

The console.log tries to evaluate this so it goes to setTimeout

it says "I don't know a this maybe try to ask logName"
we get to logName (which is also defined as an => so it cannot bind a this) and ask and it says "this doesn't ring a bell, maybe ask person?"
now we ask person and it's like "Hey I don't have any property called this I can't help."

Eventually we get all the way to the global Window object because that's the default when this isn't bound to anything in the context which we called it.

Why use an Arrow Function?

Okay, that was confusing. this in relation to Arrow Functions is arguably the hardest thing to grasp. So let's talk about something easier to grasp and results in some clean looking code.

As mentioned, Arrow Functions can result in much shorter, cleaner code for us and especially in short function definitions or when using map or reduce.

Let's take a look.

// ES5
function addTwoNums(x, y) {
  return x + y
}

// ES6
const addTwoNums = (x, y) => {
  return x + y
}

Doesn't look any shorter in ES6, right? One great feature of Arrow Functions is if we have one statement and want to return we don't use the {} or the return keyword.

const addTwoNums = (x, y) => x + y

There's an implicit return when no braces or return is present with an Arrow Function. This really helps when it comes to the readability of a map or reduce usage.

const nums = [1, 2, 3]

const doubledNums = nums.map(num => num * 2)

You may have noticed this time when using the Arrow Function in map we didn't put parenthesis around the parameter.

When there is only one parameter for an Arrow Function the parenthesis are optional.

So parenthesis can be optional and in certain scenarios the brackets and return can be omitted providing us multiple ways to write the same code. Going for the shortest code is usually what I would do - but again, personal preference.

/* * These are ALL equivalent * */
// ES5
const doubledNums = nums.map(function(num) {
  return num * 2
})
// ES6
const doubledNums = nums.map((num) => {
  return num * 2
})
// ES6: No brackets - implicit return
const doubledNums = nums.map((num) => num * 2)
// ES6: Single parameter - no parameter parenthesis
const doubledNums = nums.map(num => num * 2)

Arrow Functions have more characteristics and gotchas than listed here but these are the basics I focused on to get a grasp. Once you get an understanding of these concepts take a peek at the MDN Arrow Functions page. You'll find plenty more use cases and confusing things to learn!

Don't get me wrong - I keep saying confusing because it's true! I learn more each day - new things I hadn't heard of or known and how my understanding of something wasn't quite right. Let me know in the comments if there's an explanation here that isn't quite right or if there's an interesting gotcha you know of.

I still love JavaScript and this Tweet speaks to that pretty well!

Stefan Natter 🇦🇹👋🏻

@natterstefan

Dear Developers,

One thing is for sure: I may drive you crazy sometimes; but in the end, you fall in love with me each and every day again.

best regards,
JavaScript ❤️

16:16 PM - 11 Jul 2020

Listening for a Form Submit in JavaScript

Nick — Mon, 06 Jul 2020 15:09:40 +0000

What is a Form Submit?

Simply put it's submitting a form... Basically, when you fill the form out with whatever information it asks for you want to do something with that information. We can do all manner of operations with this data and that's dependent upon your application's tasks and the purpose of the form.

A contact form should provide ways to get in touch with a specific person; a suggestion form should include an issue or improvement to be logged; an email subscription sign-up should have... well, an email. You get the point.

How do we listen for the submission?

First, we're grabbing the element (the form in this case) that we want to listen to. Keep in mind, this is using the basic form element selector. If you have multiple forms on your page this will only return the first occurrence of a form.

If you do have multiple forms, you'll want to add an id tag to each form specifying what it's for - that way you can safely select the form you want and attach the appropriate event listener.

  const form = document.querySelector('form')
  form.addEventListener('submit', (event) => {
    // Add code for functionality you need here
  })

Or you can simply chain the method calls like so...

  document.querySelector('form').addEventListener('submit', (event) => {
    // Add code for functionality you need here
  })

This chaining is especially useful when you know you'll only have one event to listen for. No need to grab the element in question and store it in a variable if you're only going to add one event listener.

Why are we not listening to the submit button?

For us to have access to the information the user has entered we listen form. The button will not actually be targeted by a submit event. The button is the submitter.

This is apparent when you look in the SubmitEvent object that is generated when a form is submitted; there is a submitter property in which you'll see the element triggering the submission. So we listen for submission on the form and the button is the one that triggers that event.

Our submit button plays a pivotal role to get this all to work, however, our form is the element on which the submit is actually fired and thus the element we should listen to.

Forem: Nick

Consistency

What tool, system, approach, reward, punishment or combination do you use to maintain consistency?

How To Deploy a Full-Stack MERN App with Heroku/Netlify

Let's get started!

Project Context

What is MERN?

Project Structure

Some Options for Deployment

Project Configuration

Deployment Process

Steps

You did it!

Let me know in the comments...

Connect NodeJS and MongoDB

Step 1: Visit MongoDB's website

Step 2: Create and Connect to a Cluster

Step 3: Setup a MongoClient

Step 4: Use your client

Moving Forward

Get Some Practice

React Lifecycle Methods - The Basics

The Basics

Mounting

componentDidMount()

Updating

componentDidUpdate()

Unmounting

`useEffect()` and `async`

The Situation

componentDidMount

useEffect()

Article Will Unmount

Starting with React Hooks

What Are Hooks?

Class-based approach

Side Note: Functional Components

Hooks

Commonly Used Hooks

useState()

useEffect()

Custom Hooks

There Is Much More to Hooks...

Callbacks vs. Promises

Callbacks

The Bad

The Good

Promises

The Bad

The Good

Final Thoughts

JavaScript Array.flat()

Removing nested Arrays

Depth

Removing empty elements

Why should we use flat()?

Scope in JavaScript

Scope

What is Scope?

Pirate Ship Analogy

Pirate Ship Scenario #1

Pirate Ship Scenario #2

Some basic examples

Arrow Function Expressions - The Basics

What is an Arrow Function Expression?

Which is better?

When to Use

When not to Use

Arrow Function: To code or not to code?

Why use an Arrow Function?

Listening for a Form Submit in JavaScript

What is a Form Submit?

How do we listen for the submission?

Why are we not listening to the submit button?

Step 4: Use your `client`

`componentDidMount()`

`componentDidUpdate()`

`componentDidMount`

`useEffect()`

`useState()`

`useEffect()`

Why should we use `flat()`?