Forem: Austin Brown

Dynamic Dependent Drop-Down Lists with MUI

Austin Brown — Sat, 19 Sep 2020 20:20:48 +0000

In my opinion, one of the most important factors that separates a polished app from an unpolished app, in terms of UX, is its methods of user input. When developing some of your first apps, you will likely run into many instances in which you will be tempted to use a simple input form that allows a user to type anything that they want, when there are actually only a limited number of specific things that they should be able to choose from—for example, when submitting a query to an API or database. Enter APIs and the Autocomplete component from Material UI, in conjunction with some other techniques we'll be going over in this blog.

Material UI is a whole separate topic which you can learn about here: https://material-ui.com/getting-started/installation/, but essentially it is a styling library with a lot of aesthetically pleasing modular components that are very easy to set up—Autocomplete, of course, being one of them.

Let's say you want to set up a car selection input screen broken down by year, make, and model—a common scenario where dynamic dependent drop-down lists may be needed. It needs to be dynamic because car models change every year—so there will never cease to be new years and models being added to this list—and dependent because the makes that appear are dependent on the year that is selected, and the models are dependent on the make selected. Fortunately, there are a lot of APIs out there specifically for seeding lists like this. For the car example, fueleconomy.gov offers an API for this exact use case.

When the selection screen is first loaded, we will need to first generate the top level of the menus—in this case, the Year selection. For this example, in React, we can use useEffect() (or componentDidMount()) for this.

const [car, setCar] = useState({});
const [years, setYears] = useState([]);
const [makes, setMakes] = useState([]);
const [models, setModels] = useState([]);

useEffect(() => {
  axios.get('https://www.fueleconomy.gov/ws/rest/vehicle/menu/year')
    .then(({ data }) => {
      setYears(data.menuItem.map((item) => item.value));
    });
}, []);

As you can see above, we are also using useState() to hold the values for each list, as well as the car that will have been selected after the third drop-down menu is fulfilled. The GET request above will retrieve a list of all years and place them in the years array. So now that we have the years populated, we will need to display them as a list.

As I mentioned, the Material UI set up should be fairly simple, as well as the Autocomplete boxes. Info for setting up and importing the Autocomplete boxes here: https://material-ui.com/api/autocomplete/

<Autocomplete
  onChange={(_, year) => getMakes(year)}
  options={years}
  renderInput={(params) => (
    <TextField {...params} label="Year" variant="outlined" />
  )}
/>

Let's break this down line by line. Within the Autocomplete component, we first have:

onChange - takes a callback function whose second parameter is the actual item that was selected. So here, when a year is selected, it will be passed to another function we will create called getMakes(), so makes specific to that year will be generated.
options - simply points to the array that holds options for the menu.
renderInput - takes a callback function which generates the actual typing input box—in this case, the MUI TextField.

Now let's look at the aforementioned getMakes() function that will need to be created.

const getMakes = (year) => {
  setModels([]);
  setCar({ year, make: '', model: '' });
  axios.get(`https://www.fueleconomy.gov/ws/rest/vehicle/menu/make?year=${year}`)
    .then(({ data }) => {
      setMakes(data.menuItem.map((item) => item.value));
    });
};

As you can see, this function will first reset the models array in case anything had previously been selected by the user. Then the car year is saved, and another endpoint from fueleconomy.gov for getting makes from a selected year is used to populate the makes array.

Then we have the selection box for makes.

<Autocomplete
  onChange={(_, model) => getModels(model)}
  disabled={!makes.length}
  key={makes}
  options={makes}
  renderInput={(params) => (
    <TextField {...params} label="Make" variant="outlined" />
  )}
/>

The only difference to note between this and the last selection box, is that since this drop-down list is dependent on the one above it, it should be disabled until there are options to select, and it should change if its options change. That is why we have added the following props:

disabled - a simple boolean. In this case, with it being set to !makes.length, disabled will be true if the makes array is empty.
key - in this case, is being used just to reset the selection and items in the drop-down menu if a new set of makes is retrieved from the API as a result of changing the year.

Setting up the getModels() function and its drop down menu should be essentially the same as the previous. In conclusion, Autocomplete in Material UI can be a super easy method for setting up dynamic dependent drop down lists. There are a lot of other cases this can be used for, like city/state selection screens, in which case you could skip the entire API retrieval method and set up a simple static array for your selection options, since cities and states do not change very often. I hope this demo has been in some way useful to you and I wish you the best of luck in your endeavors.

Thanks!

Overview of Authentication with Cookies

Austin Brown — Sun, 13 Sep 2020 23:49:00 +0000

Even if you're already familiar with the process of cookies being saved to a web browser, the overall process can often become a bit lengthy and confusing to follow, especially when combined with third party access delegation. Now, obviously, if you aren't a developer then none of this would matter to you, but if you are, there's definitely a lot of useful information to know about this process—even if you aren't directly working with authentication.

While cookies have many purposes, the purpose that I'll be talking about, as I have implied, is quick and seamless authentication. I'm sure you've encountered it countless times with websites, especially with social networking websites like Facebook, Twitter, YouTube, and so on. You log in once, and each time you come back after you're already signed in.

Conceptually, you could think of this process as very similar to a coat check or a valet. Once you leave your car with the valet, they need some uniquely identifying piece of information to give you that they will quickly be able to associate with your car the next time you come back and show it to them, so that they know what to give you.

Likewise, when you first log in to your account on a website, a cookie is generated on the server and sent back to your browser, and your browser stores that cookie. When you inevitably leave that website, the next time you come back, your browser will present the cookie this website gave it. The server for this website will then find the account it associated with this cookie and send it back to your browser.

In addition to the convenience this provides to the user, it also makes it much easier for the server to keep track of each user. With the user data being injected into every request as it is received by the server, the server can then carry out said requests specific to the user who is requesting it.

Now let's take a look at an example of this process from a Node server using Express, Passport, and Google OAuth.

passport.use(new GoogleStrategy({
  clientID: OAUTH_CLIENT_ID,
  clientSecret: CLIENT_SECRET,
  callbackURL: '/auth/google/redirect',
},
(async (accessToken, refreshToken, profile, done) => {
  const { familyName, givenName } = profile.name;
  let user = await User.findOne({ where: { id: profile.id } });
  if (!user) {
    user = await User.create({
      first_name: givenName,
      last_name: familyName,
      email: profile.emails[0].value,
      photo: profile.photos[0].value,
    });
  }
  done(null, user);
})));

Above is an instance of Passport being used on a server to authenticate with Google to sign up users. During the initial sign up process after being redirected back to the original website from the Google Sign in page, the asynchronous callback function seen in the second half of the above code snippet is fired. In that function, you can see it first checks to see if the a user already exists in its connected database using the information it got from Google. If the user does not exist, it will create an account using that information.

After creating an entry for the user in its connected database, the server will then take a uniquely identifying piece of information from that and create a cookie to send back to the browser. This is like the valet giving you a ticket to show them the next time you come back, only a little more complicated. Since it would be too easy for someone else to falsify or guess this information, Passport, and other services like it, will use a form of encryption to scramble this information before sending it back. That's where Passport's serializeUser() method comes in.

passport.serializeUser((user, done) => {
  done(null, user.googleId);
});

This method performs the aforementioned encryption before passing the cookie along to be sent back to the browser. In the above example, the user's Google ID is being used as the uniquely identifying information.

Finally, as you may expect, there is an accompanying deserializeUser() user method to reverse this process and look up the user's account the next time the browser makes a request with that cookie, which looks a little something like this:

passport.deserializeUser(async (googleId, done) => {
  const user = await User.findOne({ where: { googleId } });
  done(null, user);
});

Conclusion

I've really only touched the surface of the entire overall process, but this should give you a little better of an understanding of how it works. Authentication is an absolutely essential part of any web application, and cookies can make that process into a seamless experience for users, as well as the developers. For a full tutorial and explanation of all the pieces working together, I would highly recommend checking out this YouTube playlist: https://www.youtube.com/playlist?list=PL4cUxeGkcC9jdm7QX143aMLAqyM-jTZ2x

**Be sure to reference the docs here: http://www.passportjs.org/docs/google/ when setting up the boiler plate code and installing the modules, as some of the specifics for that in the videos seem to be a bit outdated.

How To Upload and Serve Photos Using React, Node, Express

Austin Brown — Mon, 07 Sep 2020 13:45:48 +0000

In this blog, I'll be going over the simplest and fastest method to upload a photo from a React client to a Node server with Express and then how to display that photo back to the client.

Assuming that you already have these components of your app set up and connected, first we'll start with a basic button and a function to handle the selected file.

<input type="file" name="file" onChange={this.uploadHandler}/>

uploadHandler(event) {
  // code goes here
}

In this demo, it should be noted that I will be showing examples using a class component, but you could just as well do this in a functional component.

Now, inside your upload handler function, you'll need to convert the file into something that can be sent in a POST request, and then send it to your server. We'll be using Axios in this example.

Here's what the upload handler function should look like:

  uploadHandler(event) {
    const data = new FormData();
    data.append('file', event.target.files[0]);

    axios.post('/upload', data)
      .then((res) => {
        this.setState({ photos: [res.data, ...this.state.photos] });
      });
  }

Here, we are creating an instance of FormData and appending the file with .append(). The file details can also be seen with a console log of event.target.files[0], in which case you may see something that looks like this:

Now, for your Express server, you'll need to install Multer if you do not have it already, via the command npm install multer. Then, add this to the .js file for your Express server above wherever your POST route is going to be:

const multer = require('multer')

const storage = multer.diskStorage({
  destination: function (req, file, cb) {
    cb(null, 'public')
  },
  filename: (req, file, cb) => {
    cb(null, Date.now() + '-' +file.originalname)
  }
})

const upload = multer({ storage: storage }).single('file')

All we really need from here is the upload function which is built from storage and multer above it. In the multer.diskStorage object above, the 'public' string in 'destination:' can be changed to whatever you want the folder name to be where your photos to be stored. This folder, by default, is in the root folder of your entire app.
Additionally, the Date.now() + '-' +file.originalname below it specifies the filename that your stored photo will be saved as. If you leave it as is, the original filename will be preserved, but with a JavaScript formatted date in front of it followed by a dash.

And now for the POST route:

app.post('/upload', (req, res) => {
  upload(req, res, (err) => {
    if (err) {
      res.sendStatus(500);
    }
    res.send(req.file);
  });
});

As you can see, the aforementioned upload() function is now handling the req and res objects from the initial Express app.post. We have some basic error handling by sending a 500 if the file can't be saved, but otherwise, it will send back information about the file that was saved. There's just one thing left that the server will need now in order to actually serve that file back to the client.

app.use(express.static('public'));

Add this near the bottom of your express server index.js file. The 'public' string here again will refer to whatever you have named the folder that will store the image files. Now let's look back at the Axios request from the client.

axios.post('/upload', data)
      .then((res) => {
        this.setState({ photos: [res.data, ...this.state.photos] });
      });

In the .then(), res.data contains an object with details about the file that was saved, one of them being the filename. this.setState({ photos: [res.data, ...this.state.photos] }); will add this object to the front of a 'photos' array in this.state.

Now, in your render(), beneath the upload button, you could add something like this: (where localhost is the host your app is being served from and 3000 is your port number)

        {this.state.photos.map(photo => (
          <img src={`http://localhost:3000/${photo.filename}`} />
        ))}

By default, with app.use(express.static('public')), the photos inside the 'public' folder will be available at the '/' endpoint followed by the filename. So the above map function should now display the photos one by one as you add them, with the most recent being at the top since we're adding them in reverse order.

Here is the final result of the code for the client side app:

import React, { Component } from 'react';
import axios from 'axios';

class App extends Component {
  constructor(props) {
    super(props);

    this.state = {
      photos: [],
    };

  this.uploadHandler = this.uploadHandler.bind(this);
  }

  uploadHandler(event) {
    const data = new FormData();
    data.append('file', event.target.files[0]);
    axios.post('/upload', data)
      .then((res) => {
        this.setState({ photos: [res.data, ...this.state.photos] });
      });
  }

  render() {
    return  (
      <div>
        <div>
          <input type="file" name="file" onChange={this.uploadHandler}/>
        </div>
        {this.state.photos.map(photo => (
          <img src={`http://localhost:3000/${photo.filename}`} />
        ))}
      </div>
    )
  }
}

export default App;

The demonstration that I've done shows the quickest, most basic way to get a file upload and retrieval system working with React, Node, and Express. You will most likely want to eventually add more advanced features like multiple file upload, more advanced error handling, a progress indicator, saving the URLs to a database, and possibly a separate process of selecting the file and uploading the file. However, the demo should be enough to get you started. There is a lot that can be done with file upload functionality in an app, so hopefully this demo will help get you started.

How To Create JavaScript Objects From an Excel File

Austin Brown — Sun, 30 Aug 2020 03:19:57 +0000

If you're like me, you might like to use excel files occasionally to keep track of certain data. It is, after all, a pretty universal standard for keeping track of numbers and having a visual interface to append to and manipulate said numbers. Well it might surprise you to know that there is a tool that can be installed with a single npm command that allows you to read data from an excel file. I will be showing in this blog how to do this, as well as how to create an object and add insert that object into a SQL database.

There are a lot of reasons this could be useful. For example, suppose a teacher has their student's grades saved in excel files and you wanted to import them into a JS app automatically. You might have a spreadsheet that looks something like this:

To get started, enter this command into your terminal (You will need Node installed as well. I am using VS code)



npm install read-excel-file

Now, in your JS file, just add this require statement to the top:



const xlsxFile = require('read-excel-file/node');

And that's the entire setup! The xlsxFile function takes a single argument—the path to your excel file as a string. The file path will be relative to the JS file that the xlsxFile was "required" on. So if you have an excel file named 'ExcelFile.xlsx' and it is in the same folder, the path would look something like: './ExcelFile.xlsx'

A successful call of the xlsxFile function will return a promise that contains an array of all the rows of your excel file. Each of those rows are also arrays which contain the value of each cell. So to bring it all together:



const xlsxFile = require('read-excel-file/node');

xlsxFile('./ExcelFile.xlsx')
  .then((rows) => {
    rows.forEach((row) => {
      row.forEach((cell) => {
        console.log(cell);
      });
    });
  });

The above function will display every single cell on the console, left to right top to bottom. Now, to manipulate that data into something more useful:



xlsxFile('./ExcelFile.xlsx')
  .then((rows) => {
    const columnNames = rows.shift(); // Separate first row with column names
    const objs = rows.map((row) => { // Map the rest of the rows into objects
      const obj = {}; // Create object literal for current row
      row.forEach((cell, i) => {
        obj[columnNames[i]] = cell; // Use index from current cell to get column name, add current cell to new object
      });
      return obj;
      console.log(objs); // Display the array of objects on the console
    });
  });

Now, each row has been converted to a JavaScript object using the first row as its key names, and every row after used to create an object with key values from their cells and key names of the name at the top of their columns—basically like an excel-to-JavaScript constructor function.

And finally, if you wanted to use an ORM like Sequelize to insert these into a database:



    xlsxFile('./ExcelFile.xlsx')
      .then(async (rows) => {
        const columnNames = rows.shift();
        const promises = rows.map((row) => { // Map the rows array into an array of promises that each create an entry in the DB
          const obj = {};
          row.forEach((cell, i) => {
            obj[columnNames[i]] = cell;
          });
          return Grade.create(obj); // 'Grade' is a hypothetical Sequelize model where the grades can be saved
        });
        await Promise.all(promises); // Use Promise.all to execute all promises
      });

And that's the tutorial! It should be noted that are limitations to the size of the .xlsx files that can be imported, although they are not explicitly stated by the developer. While this may not be the absolute most practical method of handling data to be switching back and forth between Excel and JavaScript data, it can certainly be useful for small projects and save a lot of time if you needed to update an older data set and import it for a JavaScript project.
More information about this app and its developer are available on GitHub here: https://gitlab.com/catamphetamine/read-excel-file

React: Using State in Functional Components

Austin Brown — Mon, 24 Aug 2020 13:17:27 +0000

Traditionally in React JS, an app would be set up in such a way that there is a main stateful class component which holds all of the state values and methods to set them with, and these values or methods would be passed to its functional children components as props. As of React version 16.8, Hooks can be used to use stateful variables directly within a functional component.

The reason it may be useful to do this is if the state values that you need to set do not need to be accessed by or do not affect any other component in the app—such as a counter of some kind or an array that holds the views for a particular component. This also can help with keeping your main App.jsx file free from being cluttered.

useState()

Getting started with this feature is extremely simple:

import React, { useState } from 'react';
function Example() {
   const [index, setIndex] = useState(0);

...

The above example demonstrates the useState() React hook. In the first line, useState needs to first be imported from the react object. The index and setIndex variables shown can be any name that you would like them to be. The first variable (in this case, index), will always be the actual current value of your state variable, and the second (typically named 'set' and then the name of the variable listed just before it) is a function used for setting said variable—just like the traditional setState() with class components. And finally, the 0 seen in the parenthesis after useState() is the initial value before anything has been set. This can be set to any data type you would like.

So inside the Example component, if you wanted to do something like increment this new index variable, it might look something like this:

setIndex(index + 1);

useEffect()

The equivalent from a traditional class component to explain useEffect() would be the componentDidMount() and componentDidUpdate(). It acts as sort of a combination of the two.

Here is an example:

useEffect(() => {
      axios.get('/api/messages')
      .then(response => {
         setMessages(response.data)
      })
      .catch(err => console.error(err));
   }, []);

Using useEffect() as shown above is the componentDidMount() equivalent. The first argument in useEffect() is the function to be called after the initial render, but the main thing to note here is the second argument passed at the end—the empty array literal. When it is left empty, the function will only ever be called after the initial render. Adding state variables to it (separated by commas) will cause the useState() instance to act more like componentDidUpdate(). This function will now also be called any time a change happens to the specified variables. And that's it!

Conclusion

These hooks are just a couple of basic ones to get started with, but alone they can completely change the way your app is structured and really simplify/cut down on a lot of your code. Additionally, no other changes need to be made to an existing React app to use these hooks other than the basic importing of the 'useState' and 'useEffect' variables, and they are one hundred percent compatible to work side by side with and inside of traditional class components as well. More information about these hooks can be found in React docs here: https://reactjs.org/docs/hooks-intro.html

Mongoose: The Basics

Austin Brown — Sun, 26 Jul 2020 16:46:21 +0000

What is Mongoose?

Mongoose is an object data modeling library (ODM) used for simplifying the interactions between a javascript application and a MongoDB database. You could think of it by comparing it to the way that jQuery simplifies making modifications to the DOM.

The Setup

First, you will need to make sure Mongoose is installed via your terminal, which can be done with the command npm install mongoose. You may want to include this in the dependencies for your package.json as well.

At the top of your file, you'll need to require mongoose like this:

const mongoose = require('mongoose');

And then the last step:

mongoose.connect('mongodb://localhost/dbname', { useNewUrlParser: true })
  .then(() => console.log('Connected to database'))
  .catch(() => console.error('Failed to connect to database'));

On the first line, localhost would be replaced with whatever IP address your MongoDB is hosted from, and dbname is the name of the database you want to use. If a database with this name does not already exist, one will be created under that name.

The useNewUrlParser: true option is simply for updating the built-in deprecated URL parser and is currently recommended for all instances of the use of mongoose.connect().

Since mongoose.connect() returns a promise, an optional .then() and .catch() can be used to display a success/error confirmation to the console as shown in the above example.

Schemas

To set up a schema, you might use a block of code that looks like this.

const usersModel = new mongoose.Schema({
  username: { type: String, unique: true },
  password: String,
});

Here, new mongoose.Schema() is used by passing an object as an argument which has key-value pairs where the key names will define column names in your table, and values that specify the data type that the column will hold. Typically it would be set equal to a variable as shown above so that that variable can then be used to create and modify entries in the table with its many built-in methods. This variable is now referred to as a model, but I like to think of it as a table since that is essentially what it is, so I will be referring to it as a table.

Some of the most common methods include:
-create() - for creating new entries in the table
-find() - for making general queries to the table
-deleteOne()/deleteMany() - for deleting entries from the table
-update() - for updating values on an existing record in the table

All of these methods accept standard JavaScipt objects as arguments. Here is a simple example using the usersSchema from earlier:

usersModel.create({
   username: 'MyUserName',
   password: 'abcd1234',
});

This would then create an entry in the table that looks like this:

Like the mongoose.connect(), each of these methods will return a promise, so .then(), .catch() and so on can be chained on to handle the response from the query as needed. This is especially useful with a method like find(), since fetching data from an external source as such needs to be handled asynchronously.

usersModel.find({
   username: 'MyUserName',
})
   .then((response) => {
      return response;
   })

Summary

Mongoose paired with MongoDB is a great duo for general purpose database handling in full-stack web development known as the MERN stack. Since the library is in JavaScript, it is ideal in the many instances where the entire stack is in JavaScript which allows for less time translating between different languages and less likelihood for bugs due to errors in translation.

Inner Join Tables in SQL

Austin Brown — Sun, 19 Jul 2020 02:12:49 +0000

In SQL and many other database programming languages, databases are set up in a specific way that is meant to minimize the amount of computing power needed to both update and make queries to the stored data. Because of this, some of the methods that they use may initially seem unintuitive to humans, but it makes a significant difference when dealing with databases that have hundreds of thousands of records in them and beyond. Inner join tables are a prime example of this and one of the first you may encounter when learning SQL.

Inner join tables are used by the computer to cross reference multiple categories (tables) of information to find information from one table that is associated with information from another table.

Imagine a scenario where a police department wants a list of everyone in a particular city that drives a certain type of car. Their database would likely have a massive amount of people to search through that is frequently changing, so a system that checked each person and each car one by one would take too long. Instead, they could set up a database that might have one table that holds addresses of people and a separate table that holds registered vehicles, each table with unique indexes that the data base can look up instantly when provided with said index. Making a query with an inner join table will return with records that have something in common between the two (or more) tables. Conceptually you could think of it like a Venn diagram.

So far this should seem pretty straightforward, but it's the actual process of comparing these tables used by inner join that can seem confusing at first. First, let's consider this very small scale example below of an Addresses table consisting of 2 addresses and the Vehicles table consisting of 3 vehicles. Assuming that the vehicles table is referring to every individual registered vehicle, this would be considered a one-to-many relationship, since any given address can be associated with multiple different vehicles but a vehicle can only be registered to one address at a time.

If you are familiar with permutations, this next part should seem familiar as well. To form a join table, the computer essentially will take every row from both tables and temporarily form this table of every possible combination from the two tables. The total number of rows would equal the product of the total rows of the 2 being joined—thus it would have 6 rows. (2 x 3)

The code to actually create this table would look something like this:

SELECT * FROM addresses INNER JOIN vehicles;

However, since this table is not very useful as it is, instead you might have a command like this:

SELECT * FROM addresses INNER JOIN vehicles 
ON addresses.id = vehicles.addressId;

By matching the Addresses IDs with the ON addresses.id = vehicles.addressId does is it filters out the paired rows that have completely irrelevant side by side information so that you will only see the relevant ones. So the addresses now have their associated vehicles next to them.

Now if you wanted to filter these results to just look at one address, you could just add on something like this:

SELECT * FROM addresses INNER JOIN vehicles 
ON addresses.id = vehicles.addressId AND addresses.address = '3782 Kennedy Ln' ;

And voila! A successfully retrieved address with its associated vehicle.

Conclusion

There are many more types of tables not covered here such as outer joins, left inner joins and so on, but inner joins are the most common and a good entry point for understanding the basics. While it is not technically necessary to know how a join table actually works or the reason that they are set up the way they are to perform a query with one, it can definitely be helpful when working with large databases and is one hundred percent necessary for the creation of a database.

Lifecycle in React

Austin Brown — Mon, 13 Jul 2020 03:08:23 +0000

In React, each stateful component goes through what is referred to in this framework as a lifecycle. Today I am going to go over a few things about these lifecycles and some of the common methods—also commonly referred to as hooks—used to control the different components of your app during the different phases of its lifecycle.

Lifecycle essentially just refers to the process of the React framework building a single component rendering it to the page, and removing it from the page (DOM). During this lifecycle, there are three main phases:

Mounting
Updating
Unmounting

Mounting

The most notable things this phase consists of are the constructor() and render() method. It is like the birth of your component. Any code in the constructor function will be executed immediately upon creating an instance of your component and affects its initial state, as constructor functions are normally known to do. The render method will usually just contain representations of the specific HTML elements that this component will consist of. Render is the only method that is actually required in a stateful component.

class App extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      done: false
    };
  }
  render() {
    return (
      <div className='some-div'></div>
    );
  }
}

Next, we have the componentDidMount() method. Anything in this method will be executed immediately after the component's initial render and after it has been mounted—even though it is technically considered part of the mounting phase. This is a good method to include fetching of any outside data that your application will need, for example, from an API. By its name, we know that the component did successfully mount and render its initial state, so this helps to prevent any reference errors from occurring when React then goes to place that data into the template of the page. This is not to be confused with the now deprecated componentWillMount() which would have the potential for causing such an error in this case if the data were fetched before the elements that were to display them had been rendered on the DOM.

  componentDidMount() {
    // Displays a search for cats by default when page loads
    this.search('cats');
  }

Updating

If the state in a component has been changed via setState() or new props have been passed to it, there is a method known as componentDidUpdate() that will be run immediately after these changes if you wish to include it—separate from the re-rending that occurs automatically. The code in this method will be executed immediately after the visual changes have finished happening in the DOM.

componentDidUpdate(prevProps, prevState) {
  if (this.props.user !== prevProps.user) {
    this.fetchData(this.props.user);
  }
}

This could be useful if changing the props that are passed into your app meant that a different API should be called or the API should be called in a different way. Usually a conditional will be used to prevent an infinite loop.

Unmounting

Finally, we have the unmounting phase. This phase pretty much exclusively consists of the componentWillUnmount() method. Right before the component dies, or rather, before it is removed from the DOM, you might want to clean up a few things that this component relied on in your code and are now no longer necessary. For example, you could clear a setTimeout() or setInterval() that a particular DOM element is using.

componentWillUnmount() {
  clearInterval(this.timer);
}

Summary

Mounting - Includes constructor(), render() and componentDidMount()
Updating - componentDidUpdate()
Unmounting - componentWillUnmount()

The only one of these methods that is actually required in a stateful component is render(). I have just touched on some of the more common methods, but there are a lot more that exist that may be useful which can be found in the docs at reactjs.org.

An Overview of APIs and REST

Austin Brown — Sun, 05 Jul 2020 23:01:37 +0000

An API, also known as an Application Programming Interface, is essentially as it sounds— an interface used by programmers for their application. To be more specific, it is an interface for the application to communicate with a server. This interface is actually a part of a server (back end) that handles requests by a client (front end).

Many companies, like Google, have different APIs offered for the many services that they offer. These APIs are often used internally or for customers. For example, Google has a downloadable Maps app that directly accesses the Maps API. It only needs raw maps data from the server for it to function, whereas a web browser accessing the Maps website will need HTML from the server in addition to maps data to build the entire GUI. The app already has everything it needs for the GUI built-in.

As for an example of customer use— most cell phone carriers provide a map on their website to show the areas that their towers provide coverage to. Instead of developing an entire maps system for this to happen, they may choose to use Google Maps API.

What is a RESTful API?

REpresentational State Transfer is a specific type of API architecture that we will be going over in this blog. A couple of key things to note about REST is that it is intended for use with HTTP which, as you may know, is already very widely adopted, and it is stateless. Stateless just means that each request made to the server is intended to contain all of the information required by the server to fulfill said request. So, for this request, we will likely need a few basic things.

An endpoint - a location to access the server in the form of a specific URL
An HTTP Verb - an operation to request of the server
A callback - a function which dictates how the data that comes back from the server will initially be handled in our application

With REST, we would typically use the methods specific to HTTP. The four most common methods/verbs are:

GET
POST
PUT
DELETE

There are many ways to use REST and many languages that it is supported in. For my demonstration, I will be using JavaScript's built-in Fetch API to go over GET and POST, since they are the most common of the four I just mentioned.

GET

fetch('http://domain.com/api')
  .then(response => response.json())
  .then(data => console.log(data));

In the above example on the first line, we have an endpoint URL to point to the data we want to 'get'. On the second and third lines, the data is then being converted from an HTTP response to JSON data, and then that data is being logged to the console. Depending on your endpoint URL, that data you get back might be an object or possibly an array. The third line is where you could place a callback of your own to do whatever you would like with that data, rather than log it to the console. Notice that the method type is never specified. This is simply because the JavaScript Fetch API by default assumes a GET request and the example is to demonstrate the simplest use case possible.

POST

fetch('http://domain.com/api', { 
    method: "POST", 
    body: JSON.stringify({ 
        username: "username", 
        password: "password", 
        id: 3
    }), 
    headers: { 
        "Content-type": "application/json; charset=UTF-8"
    } 
}) 
.then(response => response.json()) 
.then(data => console.log(data));

In this example, we can see that 'fetch' is taking a second argument of an object. This object specifies the type of request it is making to the server (POST), provides an object in the form of a string using JSON.stringify(), and specifies that data type in the 'header' property. This could be used to either submit data that will be saved to the server or to submit data that the server will process and then send something back. Referring back to the Google Maps example, you could imagine submitting a zip code in a POST request and then the Google Maps API returning a location to display on the map.

Conclusion

RESTful APIs can be very useful for their flexibility and scalability. REST is also very widely used across the web and is considered easier to use than alternatives like SOAP. REST has been growing rapidly in recent years, and in 2017, a massive API directory ProgrammableWeb reported over 80% of its profiles used REST architecture. So I think it would be safe to say that REST is an important and useful type of API to know about!

JavaScript Instantiation Patterns and Their Key Differences

Austin Brown — Sun, 28 Jun 2020 21:13:18 +0000

Instantiation patterns, in short, are methods (not necessarily a JavaScript method) by which we can create multiple instances of objects that share the same initial properties/methods. Assuming that you already have a basic understanding of this concept and why you would want to do it, let's get right into it.

The five main types are:

Functional
Functional Shared
Prototypal
Pseudoclassical
Pseudoclassical ES6

Each one in the list is generally considered to be better than the last, but I mainly would like to go over their differences abstractly and show some examples.

Functional

Perhaps the most simplistic of the bunch would be the first in this list; Functional. Let's look at a basic example of how this would be set up.

const Person = function(nameLast, nameFirst, age) {
  const obj = {};
  obj.fullname = `${nameFirst} ${nameLast}`;
  obj.age = age;
  obj.isMillenial = function() {
    return age >= 24 && age <= 39;
  }
  obj.rename = function(nameLast, nameFirst) {
    obj.fullname = `${nameFirst} ${nameLast}`;
  }
  return obj;
};

const austin = Person("Brown", "Austin", 26);

Below is what the object "austin" would look like as created on the last line.

As you can see, the idea is to eliminate the need to manually type out the property names or add the methods each time you want to create a new object—in this case, a person object.

This one probably has the least advantages, other than that it is simple to understand/write and achieves the intended goal of saving time and lines of code.

Functional is fine for small sets of data, however, it is generally considered the least efficient because for every new object the code is copied in memory and thus is not as efficient as it could be as you'll see in later examples.

Functional Shared

Functional Shared's main differences from traditional Functional are that the methods that all instances share take up less space in memory since they can all point to the same location in memory for each function instead of copying them each time.

Here is an example of Functional Shared that will create the same instances as the last example:

const Person = function(nameLast, nameFirst, age) {
  const obj = {};
  obj.fullname = `${nameFirst} ${nameLast}`;
  obj.age = age;
  Object.assign(obj, methods);
  return obj;
};

const methods = {
  isMillenial: function() {
    return this.age >= 24 && this.age <= 39;
  },
  rename: function(nameLast, nameFirst) {
    this.fullname = `${nameFirst} ${nameLast}`;
  }
}

const austin = Person("Brown", "Austin", 26);

The main drawback with Functional Shared, as opposed to some of the more advanced instantiation patterns, is that if you decide to alter the shared methods ("const methods" in the example) at any point after creating an instance ("const austin" on the last line), those changes will not be reflected in any of the instances created before this point, and all of the new instances will point to a new set of methods.

Prototypal

The most important change in Prototypal is the introduction of "Object.create()". "Object.create()" is a JavaScript method which fixes the aforementioned problem in Functional Shared.

As expected, here is another example:

const Person = function(nameLast, nameFirst, age) {
  const obj = Object.create(methods);
  obj.fullname = `${nameFirst} ${nameLast}`;
  obj.age = age;
  return obj;
};

const methods = {
  isMillenial: function() {
    return this.age >= 24 && this.age <= 39;
  },
  rename: function(nameLast, nameFirst) {
    this.fullname = `${nameFirst} ${nameLast}`;
  }
}

const austin = Person("Brown", "Austin", 26);

On the second line, "Object.create()" basically combines the purpose of the second and fifth from the previous example and adds additional functionality. "Object.create()" will permanently extend the methods passed as an argument onto the instances created with it. Now, if say we decide to add a new method to "const methods", all instances, no matter when they were created relative to when this change is made, will show the new method.

Pseudoclassical

In Pseudoclassical, we introduce ".prototype" and "new" and change the use of "this" keyword.

const Person = function(nameLast, nameFirst, age) {
  this.fullname = `${nameFirst} ${nameLast}`;
  this.age = age;
};

Person.prototype.isMillenial = function() {
    return this.age >= 24 && this.age <= 39;
};
Person.prototype.rename = function(nameLast, nameFirst) {
  this.fullname = `${nameFirst} ${nameLast}`;
};

const austin = new Person("Brown", "Austin", 26);

Instead of extending our methods onto each object, we add methods directly to the 'class' of "Person" using ".prototype" and a constructor function creates the objects. On the last line, 'new' sets the context for the 'this' keyword seen in the code above to refer to whichever specific instance you create (such as 'const austin' on the last line).

Pseudoclassical ES6

The main difference here is just that the syntax is brought up to ES6, so it looks a little cleaner and has new keywords "class" and "constructor".

class Person {
  constructor(nameLast, nameFirst, age) {
    this.fullname = `${nameFirst} ${nameLast}`;
    this.age = age;
  };
  isMillenial() {
      return this.age >= 24 && this.age <= 39;
  };
  rename(nameLast, nameFirst) {
    this.fullname = `${nameFirst} ${nameLast}`;
  };
};

const austin = new Person("Brown", "Austin", 26);

Summary

*(each issue fixed continues on to the patterns that follow)

Functional

Simple/Readable
Inefficient

Functional Shared

Introduces "this" keyword
More efficient than Functional
Shared methods will not change after instantiation

Prototypal

Introduces "Object.create()"
Fixes shared methods issue from Functional Shared

Pseudoclassical

Introduces ".prototype" and "new" instead of "Object.create()"
Constructor function - eliminates need for declaring object literal
Takes less code to write than Prototypal

Pseudoclassical ES6

ES6 syntax (cleaner, less code, introduces "class" and "constructor" keywords)