DEV Community: Mac Little

Using Google's OAuth, Passport.js , and Express for Authorization - Part 3

Mac Little — Sun, 26 Jul 2020 20:11:46 +0000

Alright folks, here it is: our third and final post detailing how we can use Google's OAuth API with Passport to give our users the ability to login as well as authenticate those users on behalf our applications behalf.

In the first part of this series, we went over how to get your Google credentials for OAuth as well as how to set up the basics for your development environment. Last week, we did a deep dive into Passport's Google Strategy and the callback function we have to give it to store that user in our application's database or retrieve that user's information if they're already in our database.

This week, we'll tie it all together. We'll create the routes we need to handle the authentication process with Express. Plus, we'll need to use another service that gives our user's browser some information that ensures that our application will remember them the next time they visit. And while that might not seem like a big deal, imagine having to log in every time you visit any website or application. That would get old pretty quickly right? We'll use cookies to avoid that.

So let's quickly review what we want to happen:

When the user goes to our login route, whether that be a button or a link, we want to send them to Google so they can sign in.
Once they sign in, we want to Google to redirect them back to our site. But if you remember from last week, our user won't return with their Google profile information in hand. They'll actually just carry a token that we need to send back to Google to get the profile information we're looking for.
Once we get that profile information sent back, we can use our Google Strategy to handle either saving the user to our database or retrieving the previously saved information.
Once the user has been saved or retrieved, we want to send them back to a page within our application. They are now officially logged in.

So now that we have these steps broken down, let's attack them one by one.

Setting up our Login Route

Since we've already initialized our app within our App.js file, we can now start mounting routes on that app, which means if we hit that particular route, from our client, we expect our server to return the appropriate response.

We can name this route whatever we want, but since we want it to handle logging in, it's probably best to name it "login".

app.get('/login', cb);

Now let's fill out the callback function that we will invoke once that route is hit. Instead of a standard request and response handler though, we'll actually use Passport's authenticate method which takes two things: the strategy we're trying to use and then the scope we're trying to retrieve from Google.

Altogether, it looks like this:

app.get('/login', passport.authenticate('google', {
  scope: ['profile', 'email'],
}));

But before we try that route out, we need go back to our Google client to handle one thing we put off: our URIs.

Setting up our Google URIs

URI is short for Uniform Resource Identifier, which is standard naming convention for services across the web to talk to each other. One URI you might be quite familiar with is a URL, otherwise known as a web address.

We need to set up URI's within our Google OAuth client to it knows where to expect to receive requests from with our Client ID and Client Secret. You can set up as many as you want, but for this example, we really only need to set up two: one for our local dev environment at port 8080 and the URL of our application (in this case, we're just using example.com).

Next, we need to tell it where to redirect our user after they've successfully logged in. Similar to our login route, this can be whatever we want, but we just need to make sure we're accounting for it in our server routes.

So in this case, we need to make sure we have a route set up for "googleRedirect", because that's where Google will send our user back with their authorization token.

Similar to our "login" route, we set up our redirect route like this:

app.get('/googleRedirect', passport.authenticate('google'), (req, res) => {
  // will redirect once the request has been handled
  res.redirect('/profile');
});

Triggering our Google Strategy with the redirect route

Again, we use passport.authenticate with our named Google strategy. Since our user is sent back to this route with their token, that will trigger our Google Strategy we built last week. We didn't really touch on this last week, but notice the callback URL listed in our options object:

passport.use(new GoogleStrategy({
  // options for the google strategy
  callbackURL: '/googleRedirect',
  clientID: process.env.GOOGLECLIENTID,
  clientSecret: process.env.GOOGLECLIENTSECRET,
}, callback);

This is how we go back to Google with our user token in hand and get their profile information. The user hits our login route, Google redirects them to the route we've set up, and then we go back to Google to quickly exchange the token for profile information and then begin our callback function that saves the user to our database or grabs the user profile we already have saved.

Establishing a session for our user

Okay, so if you remember, I closed last last week's post with these two functions:

passport.serializeUser((user, done) => {
  // calling done method once we get the user from the db
  done(null, user.googleid);
});

passport.deserializeUser((id, done) => {
  // need to find user by id
  // calling once we've found the user
  getUser(id)
    .then(currentUser => {
      done(null, currentUser[0]);
    });
});

Similar to authenticate, serializeUser and deserializeUser are two Passport methods that we use as either the final piece of logging in or saving the user from logging in when they come back to our application.

In the first case, when the user logs in for the first time, we want to set up what's called a session between the application and our user. We keep track of these sessions by storing a cookie in the user's browser. Within that cookie is a specific identifier that we can use to identify that user in the future when they come back.

But we don't want to store that id directly in the cookie, because that's a little unsafe to be giving a unique identifier that our user could "lose" or have stolen from him by impolite hackers.

That's what we use serializeUser for. After we have our user saved and retrieved from our database, we call serialize with our user and Passport's done method, calling done with that user's googleid, which will be the unique id we choose. But again, it could be something like the user's username or database id.

Once that done method is called, we use one last npm package: cookie-session. This package will dictate how long we want our cookie to last (maxAge property) as well as how we'd like to encrypt that googleid before we send it back to the user (keys property).

Of course, we need to install cookie-session first:

npm i cookie-session

Then we can use it in our app:

app.use(cookieSession({
  // age of the cookie in milliseconds
     // cookie will last for one day
  maxAge: 24 * 60 * 60 * 1000,
  // encrypts the user id
  keys: [process.env.COOKIEKEY],
}));

The keys property can just be a string of random letters, because cookieSession will use that to encrypt the googleid.

Conversely, deserializeUser will take in a session's cookie data and decrypt that cookie to find the googleid with that same key, thus allowing use to us to go grab that user from our database.

The last thing we need to do to set up a session is call passport's session method and use it in our app.

app.use(passport.session());

Sending our user back to our application

Believe it or not, but almost everything we just did is handled in the passport authenticate method inside of our googleRedirect route. Google's redirect triggers the request and now that we've handled the authentication and established a session with a cookie we're passing back back to our user, we can finally redirect that user to something like their profile page, which will take all the data we just saved and retrieved and send it back to the page, which we can use to render personalized components like an image or other data tied to that user's id.

Our final App.js page

Okay, so we've done quite a lot so let's get one big look at our App.js page that includes everything we've touched in the past three posts.

// bringing express into our project
const express = require('express');
// bringing cookie-session to our project
const cookieSession = require('cookie-session');
// bringing passport into our project
const passport = require('passport');
// bringing a Google "plugin" or Strategy that interacts with Passport
const GoogleStrategy = require('passport-google');
// brining in our getUser and createUser methods from our database methods file
const { getUser, createUser } = require('../db/methods');

// initializing our app by invoking express
const app = express();

// initialize passport to be used
app.use(passport.initialize());
// using session cookies
app.use(passport.session());
// using cookieSession in our app
app.use(cookieSession({
  // age of the cookie in milliseconds
     // cookie will last for one day
  maxAge: 24 * 60 * 60 * 1000,
  // encrypts the user id
  keys: [process.env.COOKIEKEY],
}));
// setting up our serialize and deserialize methods from passport
passport.serializeUser((user, done) => {
  // calling done method once we get the user from the db
  done(null, user.googleid);
});

passport.deserializeUser((id, done) => {
  // need to find user by id
  getUser(id)
    .then(currentUser => {
      // calling done once we've found the user
      done(null, currentUser[0]);
    });

// setting our login and redirect routes
app.get('/login', passport.authenticate('google', {
  scope: ['profile', 'email'],
}));

app.get('/googleRedirect', passport.authenticate('google'), (req, res) => {
  // will redirect once the request has been handled
  res.redirect('/profile');
});

// setting up our Google Strategy when we get the profile info back from Google
passport.use(new GoogleStrategy({
  // options for the google strategy
  callbackURL: '/googleRedirect',
  clientID: process.env.GOOGLECLIENTID,
  clientSecret: process.env.GOOGLECLIENTSECRET,
}, (accessToken, refreshToken, profile, done) => {
  // passport callback function
  const {
    id: googleId, 
    displayName: username, 
    given_name: firstName, 
    family_name: lastName, 
    picture: photo, 
    email: email,
  } = profile;

  const user = {
    googleId,
    username,
    firstName,
    lastName,
    photo,
    email,
  };

  getUser(googleId)
    .then(currentUser => {
      currentUser;

      // if the response includes a user object from our database
      if (currentUser.length) {
        done(null, currentUser[0]);
      } else {
      // if not, create a new user in the database
        createUser(user);
        getUser(googleId)
          .then(newUser => {
            newUser;
            done(null, newUser[0]);
          })
          .catch(err => console.log(err));
      }
    });
}));

// assigning the port to 8000
const port = 8000;

// calling the listen method on app with a callback that will execute if the server is running and tell us what port
app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

Closing thoughts

Authentication can be quite the task. This blog series alone was three pretty big posts. But my hope is that by systematically breaking each piece down, you'll walk away with not only a better idea of how you can incorporate Google's OAuth into your project with the help of Passport, but also a better understanding of Node.js and Express.

While there is a lot of complexity on the surface, it really is as simple as understanding what you're sending out, what you'll get back, and then acting appropriately with that data.

Plus, given the asynchronous nature of the web, authentication with a third party like Google is a great exercise in handing multiple requests with something as simple as a user hitting a "login" route.

If you have any additional questions or feedback, feel free to leave a comment or message me directly.

Using Google's OAuth, Passport.js , and Express for Authorization - Part 2

Mac Little — Sun, 19 Jul 2020 23:34:04 +0000

Okay, so last week we started the process of implementing user authentication with the help of Google's OAuth API and Passport.js. On the server side, we're using Node.js and Express for middleware.

We covered some basics like how to get our Google Client Id and Client Secret and then we set up our Google Strategy within Passport to handle some the functionality under the hood.

Just as a reminder here's what it looked like:

passport.use(new GoogleStrategy({
  // options for the google strategy
  callbackURL: '/googleRedirect',
  clientID: process.env.GOOGLECLIENTID,
  clientSecret: process.env.GOOGLECLIENTSECRET,
}, callback);

What we didn't cover was the callback function inside of that Passport object, so let's discuss that in a little more detail.

But to do that, let's first visualize this entire authentication process a little bit with the help from Google's OAuth documentation:

These arrows can be a little confusing so let's break them down step by step:

Our user visits our application and wants to login. For our application, we're only giving the user the option to sign in through Google.
Google informs the user that our application is asking for their information and by signing in, they are giving Google permission to pass their data back to us.
Once the user signs in, Google redirects the user back to our application but within that redirect, the user is also carrying something important: an authorization code.
When the user returns to our site, we aren't immediately given their info. Instead, we're given this authorization code, which we then have to go back to Google and say "Hey, we're good, they came back with this code, can we get their info now?" Google obliges.
Once we have that user data from Google, we can do two things: save that user to our database if they've never visited our website before or, if they have, render the application with any additional data they've saved within our application before.

Our Callback Function

While that seems like a lot of steps, the callback function we've been talking about manages almost all of these for us, so let's finally take a look at that:

(accessToken, refreshToken, profile, done) => {
  // passport callback function
  const {
    id: googleId, 
    displayName: username, 
    given_name: firstName, 
    family_name: lastName, 
    picture: photo, 
    email: email,
  } = profile;

  const user = {
    googleId,
    username,
    firstName,
    lastName,
    photo,
    email,
  };

  getUser(googleId)
    .then(currentUser => {
      currentUser;

      // if the response includes a user object from our database
      if (currentUser.length) {
        done(null, currentUser[0]);
      } else {
      // if not, create a new user in the database
        createUser(user);
        getUser(googleId)
          .then(newUser => {
            newUser;
            done(null, newUser[0]);
          })
          .catch(err => console.log(err));
      }
    });
};

Wow, that's a doozy! But again, by breaking this down with the steps we listed before, this can make a lot more sense.

Breaking down the callback

What's not in this function are steps 1 through 3, our user has signed in and Google has delivered what they call their "profile", the object that contains all the user info we've requested. But we probably aren't saving all of that profile info to our database and we probably aren't going to name it the same thing they do.

For example, Google saves what is typically considered someone's last name as the key of "family_name", so we'll need to take the value stored there but then re-name the key to whatever our database is expecting.

All of that is done in this part here:

// destructuring the profile object from Google, creating new variable names to be stored in our user object
const {
    id: googleId, 
    displayName: username, 
    given_name: firstName, 
    family_name: lastName, 
    picture: photo, 
    email: email,
  } = profile;

//creating our user object with all of our new user variables stored as keys

  const user = {
    googleId,
    username,
    firstName,
    lastName,
    photo,
    email,
  };

Next we need to handle step 5 to determine if this user is new (which in that case we need to save them to our database) or, if they've been here before, we need to load our application with their previously entered data. Since we're storing the user's Google ID, that's a perfect thing to look for since we can be sure that it's unique.

One note about this section: this could look different depending on what database you're using and how your database returns data you're searching for, but the overall logic will be similar. For this project, we're using PostgreSQL and PG Promise, which returns an array when searching for a user. If the user is new, you'll get an empty array. If not, that user object will be stored at the index of 0 in the array.

// get the user with this Google ID stored in our database
  getUser(googleId)
    .then(currentUser => {
      // if the response includes a user object from our database
      if (currentUser.length) {
        // call done with that user
        done(null, currentUser[0]);
      } else {
      // if not, create a new user in the database
        createUser(user);
      // once created, retrieve that newly created user
        getUser(googleId)
          .then(newUser => {
      // call done with that newly created user
            done(null, newUser[0]);
          })
          .catch(err => console.log(err));
      }
    });

See, that wasn't so bad! To be frank, the hardest part about this function is building your database methods like getUser or createUser. Once those are operating like you designed them to, it's just a matter of chaining some .then's to your functions (well, in this case, since PG Promise returns a Promise) to complete the cycle.

Looking at our App.js file thus far

Alright, so we've added our callback to our promise object, so let's do a quick review of our app.js file so far. Like I mentioned last week, it's generally better to separate parts that don't directly have to do with your app's server into other files, but we're keeping it on one page for simplicity.

// bringing express into our project
const express = require('express');

// bringing passport into our project
const passport = require('passport');

// bringing a Google "plugin" or Strategy that interacts with Passport
const GoogleStrategy = require('passport-google');

// initializing our app by invoking express
const app = express();

passport.use(new GoogleStrategy({
  // options for the google strategy
  callbackURL: '/googleRedirect',
  clientID: process.env.GOOGLECLIENTID,
  clientSecret: process.env.GOOGLECLIENTSECRET,
}, (accessToken, refreshToken, profile, done) => {
  // passport callback function
  const {
    id: googleId, 
    displayName: username, 
    given_name: firstName, 
    family_name: lastName, 
    picture: photo, 
    email: email,
  } = profile;

  const user = {
    googleId,
    username,
    firstName,
    lastName,
    photo,
    email,
  };

  getUser(googleId)
    .then(currentUser => {
      currentUser;

      // if the response includes a user object from our database
      if (currentUser.length) {
        done(null, currentUser[0]);
      } else {
      // if not, create a new user in the database
        createUser(user);
        getUser(googleId)
          .then(newUser => {
            newUser;
            done(null, newUser[0]);
          })
          .catch(err => console.log(err));
      }
    });
}));

// assigning the port to 8000
const port = 8000;

// calling the listen method on app with a callback that will execute if the server is running and tell us what port
app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

Next week

In the last part of this series, we'll wrap everything up by setting up our routes, which are essentially the strike of the match that get this authentication process started. Plus, these routes are crucial both when the user goes to Google but also when that user comes back with that access code.

And finally, there are some other functions that Passport gives us that we need to use to help our user avoid logging in every time they visit our page.

Just like last week, here are some of the functions that we'll be talking about. Notice something interesting? These functions use a done method just like our callback. Might be important to figure out what exactly that method does, right?

passport.serializeUser((user, done) => {
  // calling done method once we get the user from the db
  done(null, user.googleid);
});

passport.deserializeUser((id, done) => {
  getUser(id)
    .then(currentUser => {
      currentUser[0];
      done(null, currentUser[0]);
    });
});

Using Google's OAuth, Passport.js , and Express for Authorization - Part 1

Mac Little — Mon, 13 Jul 2020 11:43:41 +0000

When we build applications, we always keep the user in mind: "the user should be able to do this" or "is this easy for the user", but who exactly is this user anyway?

Well, depending on the application, it may not matter.

For example, if our application just renders a random SAT word to the screen every refresh, the user isn't super important. But what if they wanted to save their favorite words for studying later?

In this scenario, remembering individual users, allowing them to save and then access information at a later date becomes pretty critical. And sure, we could just create a login page and let the user create a profile, but how can we confirm they are who they say they are? And do we really want to be in charge of storing a user's password?

That's where third-party authentication from popular services like Google come in. In modern web applications, there are a variety of ways we can authenticate a user (email or text confirmation, for example), but for this series we're going to focus on two things:

Using the Google OAuth API for authentication in your Node.js project, with Express as your middleware.
Utilizing Passport.js to use that data you get back from Google to supercharge your applications with authentication you can trust.

Today, we'll focus on the first part: making an API call to Google to get some user information that we ca use in Part 2 to create a new profile for our application. This will be particularly helpful if you're not super familiar with the Google's Developer Console.

This tutorial also assumes you have a pretty basic understanding of Node.js and Express middleware.

1. Enable External under OAuth Consent Screen

The very first step we need to take is configuring how to we want our app to be made available. If we select Internal, it will only be available to users within our organization (i.e. a company or school's Google account), so we want to select External.

2. Go to the Google Developer's Console and enable your OAuth 2.0 Credentials

Next, let's get our credentials.

Google provides a wealth of APIs that you can use, whether it be for Maps or YouTube. In fact, they have so many APIs that it can be quite overwhelming.

The good news is that we don't even need to look into their API list for this project.

Speaking of which, make sure are inside a Project folder. If you don't have one, just navigate to the top left of the nav bar and click the dropdown and click New Project.

Next, click Credentials in the left nav bar, once you're in the credentials area, click Create Credentials, then OAuth client ID.

Select "Web Application" for Application type and then name your Web client. We'll ignore "Authorized JavaScript origins" and "Authorized redirect URIs" for now, but we'll definitely be coming back to those.

Once you hit Create, your Client ID and Client Secret will be generated. With these two keys, you'll be able to first send a user to Google to login. Since you've consented with your login, they'll then return data like a user's email or profile image back to you in order for you to build a profile on your site.

3. Set up your coding environment

Even if you've already set up a boilerplate with something like Create React App, we still need to install a few dependencies to make everything flow together.

// will install express for our middleware
npm i express

// will install passport that interacts with Google
npm i passport-google

Typically, it's best practice to leave your app.js file (the file that runs your server) alone. Meaning, if you want to add any routes or methods, put them in another file. However, to keep everything in front of us for now and make it a little easier to follow along, I'm going to share what our app.js file should look like thus far:

// bringing express into our project
const express = require('express');

// bringing passport into our project
const passport = require('passport');

// bringing a Google "plugin" or Strategy that interacts with Passport
const GoogleStrategy = require('passport-google');

// initializing our app by invoking express
const app = express();

// assigning the port to 8000
const port = 8000;

// calling the listen method on app with a callback that will execute if the server is running and tell us what port
app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

While it doesn't look like much, we now have a file set up that will not only allow us to access Google's sign-in page, but also take that data do something like store it in our own database, giving our users the ability to have their own unique profile.

Best of all, we have to do very little data collection ourselves, whether that be a login form or password generation/storage.

Next Week

Next week, we'll talk about how to combine Google and Passport's powers. In the mean time, here's a little code snippet that gives you a slight idea on how they work together. The "callback" is a placeholder for a slightly more complicated function, but just know it is responsible for doing something with our Google data once we get it back.

Given some of the variables we've listed in our app.js and some of the things we set up in the developer console, how is this snippet working?

passport.use(new GoogleStrategy({
  // options for the google strategy
  callbackURL: '/auth/google/redirect',
  clientID: process.env.GOOGLECLIENTID,
  clientSecret: process.env.GOOGLECLIENTSECRET,
}, callback);

A Simple Introduction to TypeScript

Mac Little — Mon, 06 Jul 2020 01:50:04 +0000

Just over a month ago, Stack Overflow released their annual Developer Survey.

Unsurprisingly, JavaScript is still the most commonly used programming language, making it eight years in a row.

And while my journey with JS is only beginning, let's say I wanted to learn another language. I could obviously just pick the second or third most popular language in the list, but popularity doesn't necessarily mean happiness, right?

Luckily, Stack Overflow's survey includes a Most Loved, Dreaded, and Wanted section which provides some interesting insights on which languages developers enjoy the most, enjoy the least, and are seeking to learn.

Today, we'll focus on the the second Most Loved language: TypeScript.

TypeScript and the Problem it Solves: Dynamic to Static

Developed by Microsoft and made public in 2012, TypeScript is considered a superset of JavaScript, which essentially means it is a powerful extension of JS.

TypeScript's main mission is simple: make JavaScript, which is a dynamically typed language, behave more like a statically typed language.

What's the difference between dynamic and static typing? Let's jump into an example:


var sayName = (person) => console.log(`Hello there ${person.name}!`)

const me = {
  name: 'mac'
};

sayName(me); // prints 'Hello there Mac!' to the console

In the above function, we create a function called sayName that just prints a welcome message to the console. But sayName is just a variable declared with var, so we can just change the value.

var sayName = (person) => `Hello there ${person.name}!`

const me = {
  name: 'mac'
};

sayName(me);

sayName = 55, // changing the value of sayName to a number

sayName(me);

And while we obviously would expect an error like this:

Why can't we at least see our first message, then see the Type Error? Because JavaScript is dynamically typed.

When we run a program, which consists of lines of code, that code is prepared to execute on whatever device or environment you've prepared, or what we call "compiled".

During this compiling phase or "compile time", statically typed languages like C# or C++ check the types and look for Type Errors before even running the program. If there is an error, the program will not run or even get to "runtime".

Conversely, dynamically typed languages like JavaScript go to runtime first then check for Type Errors. This can be particularly dangerous as programs expand in size, whether it be lines of code, files the code is distributed across, or both.

At least with our simple error above, we can easily re-trace our steps back to the re-defining of sayName a few lines above. In bigger applications, debugging is never that easy.

Thus, TypeScript was developed with the goal of bringing this "type check" to JavaScript before runtime to make our lives easier. So let's utilize TypeScript in a very simple way.

Implementing TypeScript

Let's borrow some code I wrote for my blog about destructuring, but with a few modifications. Here's what it looks like before we install and utilize TypeScript:

const slamDunk = ({first, last, points, team}) => {

  console.log(`${first} ${last} with the slam! The ${team} lead by ${points}!`);
}

const zion = {
  first: "Zion",
  last: "Williamson",
  team: "Pelicans",
  points: 2
};

slamDunk(zion);

This prints the following message the console:

Zion Williamson with the slam! The Pelicans lead by 2!

You'll notice that even through 2 is a number inside of our object, the template literals convert it to a string.

To re-factor this function using TypeScript, we have to do a few things. First, we need to install two dependencies: TypeScript and ts-node, which allows us to test our files directly in the terminal.

npm install -g typescript
npm install -g ts-node

Next, we need to create a TypeScript file using the .ts extension and then start writing our code. Here's our slamDunk.ts file in its' entirety.

Next, let's break down the key differences in this file from our plain JavaScript snippet above.

First, you'll notice that instead of going straight to our function, we have what is called an interface. An interface is a way for developers to explicitly declare what an object (in this case, a Player object) should contain, both for the keys, but also the types those values should be at the keys.

interface Player {
  first: string;
  last: string;
  team: string;
  points: number;
}

In the slamDunk function, we still have a player parameter, but again, we're explicitly stating that whatever inputs we take in must match the Player interface.

If the input matches our interface, we'll destructure it inside the function and then print our message.

const slamDunk = (player: Player) => {
  const {first, last, team, points} = player;
  console.log(`${first} ${last} with the slam! The ${team} leads by ${points}!`)
}

You'll notice that our zion variable remains unchanged. So if we run this command in the terminal:

ts-node slamDunk.ts

We'll get this message:

Zion Williamson with the slam! The Pelicans leads by 2!

This is all well and good, but this doesn't really display the power of TypeScript, so let's make some changes to our zion variable.

const zion = {
  first: "Zion",
  last: "Williamson",
  team: "Pelicans",
  points: "2" // changing the value to a string of 2
};

Our linter is already making noise, but let's try to run this in our terminal, just for kicks.

TSError: ⨯ Unable to compile TypeScript:
slamDunk.ts:21:10 - error TS2345: Argument of type '{ first: string; last: string; team: string; points: string; }' is not assignable to parameter of type 'Player'.
  Types of property 'points' are incompatible.
    Type 'string' is not assignable to type 'number'.

// this refers to the line of code where the error is
21 slamDunk(zion);

What this error tells us is that the key "points" is a string and not number, so our code can't be compiled as designed and thus won't be executed.

In our JavaScript example, this would still work. In fact, it might be preferred so we don't have to rely on the template literal changing the number to a string.

But with TypeScript, if it doesn't match the pre-determined type, it doesn't execute.

What if we tried to call slamDunk with an object that was missing one of our keys?

const lebron = {
  first: "LeBron",
  last: "James",
  team: "Lakers",
};

slamDunk(lebron);

We'd still get an error because "points" is actually missing this time.

TSError: ⨯ Unable to compile TypeScript:
slamDunk.ts:30:10 - error TS2345: Argument of type '{ first: string; last: string; team: string; }' is not assignable to parameter of type 'Player'.
  Property 'points' is missing in type '{ first: string; last: string; team: string; }' but required in type 'Player'.

30 slamDunk(lebron);

As we can see, while TypeScript is being compiled, it looks at all the variables and checks if it matches our rules. If it doesn't run. And better yet, the "errors" we get give us a specific reason the code can't compile: it doesn't follow our rules.

Conclusion

JavaScript is an incredible language and isn't going anywhere, but you probably didn't need me to tell you that. It's flexible, accommodating, and easy to learn, but like any system in technology, it comes with inherent trade-offs. Too much flexibility can lead to errors down the line, so utilizing TypeScript is a great way to control for any bugs that could potentially pop up.

And since TypeScript is just an extension of JavaScript, it's no different than pulling up the bumpers at the bowling alley. You can shoot down the middle all you want and one misstep won't send you in the gutter.

Comparing SQL and NoSQL Databases

Mac Little — Mon, 29 Jun 2020 13:06:22 +0000

Introduction

A few years ago, The Economist published an article claiming that data was the "new oil". Now, the piece focuses more on the role of some of the bigger tech companies in our modern "oil" economy, but the point still stands: data is a powerful resource.

Thus, you could argue that it's very important that developers like us do everything we can to understand the safest, most scaleable, and most responsible ways to be good stewards of this data.

Good stewardship can mean a lot of things, but today we're going to focus on data storage. And while storage is admittedly not the most exciting of topics, we'll learn later how storing data could be one of the biggest decisions you make when building your application.

For storage, we typically utilize a database. Generally speaking, there are two types of databases: SQL (stands for "structured query language") and NoSQL ("not only SQL"). While their main responsibility is the same, there are some fundamental differences that are pretty important when thinking about building your app, so let's talk about the biggest one and then quickly touch on some of the most popular SQL and NoSQL systems.

SQL Databases are relational

So what does relational mean?

Well, over the past few weeks, we've been working on some group projects that require us to use a SQL database. Believe it or not, our longest group meetings have been entirely focused around designing the schema or the organization of our data. The reason why this can take quite long is because how you design your schema will directly impact not only how your data is stored, but also how you can access it.

In a way, you almost have to completely visualize your data flow to ensure you're accounting for all the data you will need and how everything will relate to another.

The image above is simple, but just complex enough to illustrate this.

Here we have a schema design that stores a player's scoring total. But in order to do that, we need to make sure we know what team the player is on, and to know the teams, we need to know which league (NBA, NFL, etc.), plus we probably have to keep track of the week that player scored these points.

Each block (leagues, teams, etc.) is what's called a table (more on that in a bit) and each entry into that table has a unique ID, which is in bold. In order to refer to the information stored in that table, we have to refer to that ID, which you can see in the lines.

Looking at that illustration gives you a pretty good idea of where the "relational" part comes from. It can certainly be a pain determining how each table will relate, but if done correctly, it gives you access to some pretty powerful queries within SQL.

NoSQL databases are not

NoSQL databases, however, are much less structured. Instead of pre-determined tables, NoSQL databases have a variety of options of storing data, but for this post we'll focus on document-oriented.

Generally, the NoSQL approach is pretty much throwing whatever you can into the pot and even changing the recipe on the fly too. Using our player score tracking example from above, forget needing the league, just create an entry (a document) with their score and throw it in!

One of the benefits to storing data is this way is the flexibility, especially when you're working with a large amount of data with varying amounts of relational components. This is why you'll generally see NoSQL databases preferred in projects focused on using Big Data or large sets of distributed data.

Using a SQL database

As I mentioned earlier, using a SQL database requires you to design your schema ahead of time, so let's build a simple table that stores Users.

For this example, we'll be using a system known as MySQL which is completely open-source and has great documentation online.

CREATE TABLE `User` (
  `Id` INT PRIMARY KEY NOT NULL AUTO_INCREMENT,
  `Username` VARCHAR(50) NOT NULL,
  `Phone_Number` VARCHAR(12),
  `Email` VARCHAR(50) NOT NULL UNIQUE,
  `Image_Url` VARCHAR(160),
);

To make an entry to that database, we just make a query like so:

INSERT INTO User (Username, Phone_Number, Email, Image_Url) 
VALUES ('hulkamania', '555-555-5555', 'me@hulkhogan.com', 'hulkSmiling.jpeg');

Once complete, we'll see a new row with all of the data we supplied lined up with the respective column. But you should notice that everything had to be in order to make sure it's implemented correctly.

Using a NoSQL database

MongoDB is one of the most widely used NoSQL databases, so let's follow the crowd. To interact with the database, we can use Mongoose which uses plain JavaScript to build our documents.

Even though MongoDB and other NoSQL databases don't require a schema, we can still use Mongoose to build one for us, but they're a lot more flexible than SQL queries.

Sticking with the wrestler theme, let's create a wrestlerSchema.

const wrestlerSchema = new mongoose.Schema({
  name: String
});

Next, we need to create a Model, which will then format all of our incoming documents.

const Wrestler = mongoose.model('Wrestler', wrestlerSchema);

// With our Model established, we can add a wrestler with the new keyword

const machoman = new Wrestler({name: 'Macho Man Randy Savage '});

Plus, we can always go back to our Schema within Mongoose and make changes as needed and there won't be any impact to the documents or Models we already have stored. Whereas in mySQL, we typically have to re-arrange an entire database.

Conclusion

It's pretty hard to understate our vital data is to our new digital world, making it extremely important that we know how to deal with it, and making it a valuable resource of information.

Choosing a SQL or NoSQL database is a big part of that exercise, so I hope this post helps you understand some of the fundamental differences. To keep things simple, I skimmed over a few details like implementation of these databases or utilizing queries in your functions, but feel to check out the links I've shared throughout the post to explore further.

Asynchronous Functions in JavaScript

Mac Little — Mon, 01 Jun 2020 10:02:02 +0000

When most of us are learning to code for the first time, we almost exclusively code in a synchronous manner, which essentially means whatever we want to do, we'll do it right now.

Take this add function for example. If we pass in two numbers, we expect the sum to be returned immediately.

funciton add(numOne, numTwo) {
  return numOne + numTwo;
}

add(4,5) // returns 9 immediately

Last week, we talked about how JavaScript is designed to "do something". For the web, since data and other resources could be spread around, this is great! We can instruct our code to grab something from a server, the server can tell us they completed the request, and then we can go about our day.

The challenge here is that these processes are almost never synchronous. This makes sense because even in a simple page render for a website, there are a lot of different things that have to be done, like loading images. But what if an image is taking too long to load?

Synchronous Code vs Asynchronous Code

In synchronous environments, a delay like this could crash our page entirely because it might give up on waiting for that image, thus potentially ending our program. This is the point of asynchronous functions.

Asynchronous functions allow developers to build a comprehensive, executable plan for all the data we need. Because without the data we intend to present to the user, we just deliver a bad experience.

To put it into New Orleans terms, it would be like someone getting too impatient that they decide to leave out an ingredient from the holy trinity in their gumbo. Let's use asynchronous functions to help us ensure this never happens.

Making Gumbo with Asynchronous Functions

For our example, we'll use SetTimeout to replicate what it's like when our program requests something from a web server. But the main idea is that we'll be executing code at different intervals and we need to account for that.

To get started, let's create an array that holds only two ingredients from the trinity: bell peppers and onions.

const ingredients = ['bell peppers', 'onions'];

We're missing celery, but someone is making a run to the store to help us start our roux. But let's say we get impatient and start to make our roux before our friend gets back.

Well, we'll definitely have something in the pot, but it will miss a key ingredient. Might as well package that gumbo up and send it to the frozen section of the supermarket.

const ingredients = ['bell peppers', 'onions'];

const pot = []; // pot for our roux

function makeRoux () {
  setTimeout(() => {
    ingredients.forEach((ingredient) => {
      pot.push(ingredient); // pushing each ingredient into the pot
    })
    console.log(pot); // will print just our two original ingredients
  }, 1000);
}

  function grabCelery(celery) {
    setTimeout(() => {
      ingredients.push(celery);
      console.log(pot); // will print all the ingredients, but we're too late!
    }, 2000); // won't print till after 2 seconds

  };

  makeRoux(); // calling makeRoux first

grabCelery('celery'); // then calling grabCelery

How can we fix this? First, we can give our grabCelery function a callback function that will execute once we can confirm that it's been added to the pot.

A callback function can be any function we want to execute once something else is complete. The function can do anything we'd like it to do, but we want it to run after we do the first thing we need to do.

  function grabCelery(celery, callback) { // adding a callback
    setTimeout(() => {
      ingredients.push(celery);
      callback()
      console.log(pot); // will print all the ingredients
    }, 2000);

  };

What callback can we pass in to our grabCelery function? Well, obviously it's makeRoux! This way, we can ensure that our celery is returned to us before we start making our roux.

  function grabCelery(celery, callback) {
    setTimeout(() => {
      ingredients.push(celery);
      callback()
      console.log(pot); // will print all the ingredients!
    }, 2000); // won't print till after 2 seconds

  };

  grabCelery('celery', makeRoux); // passing in makeRoux as our callback

console.log(pot); // will print ['bell peppers', 'onions', 'celery']

Again, like we talked about last week, JavaScript is a single-threaded, downhill language, it doesn't do well with uncertainty and it's not very patient, so we have to use asynchronous functions to give it a little time to grab that celery or continue downloading that video even through we want to watch it now.

Conclusion

This idea of accounting for asynchronous activities is one of the most important concepts you can learn in JavaScript. While our example above is perhaps a little too simple, the main takeaway is that we have to tell our functions how to behave, especially when there are some factors outside of our control. In the next post, I'll talk about some specific JavaScript methods we can use to ensure asynchronous functionality.

A Simple Comparison of JavaScript and Python

Mac Little — Mon, 25 May 2020 15:54:00 +0000

The Goal of this Post

In my many previous attempts to learn to code, I probably spent way too much time thinking about which language I should learn first. For the most part, I was torn between Python or "Java-something" (like I said, many previous attempts).

At the time, it seemed like every blog I read or person I talked to said the same thing: "It doesn't matter, just pick one". And while I whole heartedly agree with them today, analysis paralysis definitely got the better of me and my programming goals and I'm sure it stands in the way of others just trying to get their sea legs.

So here's my hope for this blog post:

Again, fully endorse "It doesn't matter, just pick one" message.
But at the same time, give people like my younger self some simple explanations that will get them closer to following step #1.

JavaScript is Scripted

Probably the biggest difference between JavaScript and Python is how they interact with your code or "flow".

JavaScript is considered a "scripting" language, which basically means it tells our code what to do. While probably a little too on the nose, think about actors. For the most part, actors just read the script that's given to them and boom, you have a movie. Sir Ian McKellen gives a great explanation in this clip.

In JavaScript, we provide the script or directions for our programs to follow. In this code example, we've created a function named action that gets our actor to say their line when prompted by our program. How will they know the line? Well, we give it to them. How will they know when to say it? We tell them to do it when we say action and reference them.

let sirIan = {
  name: 'Sir Ian McKellen',
  role: 'Gandalf',
  line: 'WIZARD, YOU SHALL NOT PASS!'

};

const action = ({line}) => {

  console.log(line);

};

action(sirIan); // will print 'WIZARD, YOU SHALL NOT PASS!' to the console

But what if we told our actor to say their lines before we gave them the script? Well, that's bad news.

const action = ({line}) => {

  console.log(line);

};

action(arnold); // will throw an error because arnold isn't defined yet

let arnold = {
  name: 'Arnold Schwarzenegger',
  role: ' Major Alan "Dutch" Schaefer',
  line: 'GET TO THE CHOPPA!'
};

Even though JavaScript functions and variables can be distributed across a file or program, it still goes one direction: downhill. So even though we eventually define Arnold, it's too late. No one can get to the choppa.

Python is Object-Oriented

Python, on the other hand, is an "object-oriented" language. As I wrote about a few weeks ago, object oriented simply means trying our best to mimic real-world objects (whether they're cars, houses, fruits, etc.) in the digital world. By building programs with object-oriented languages like Python, we create objects that have unique attributes (like color, shape or name) and methods, and then let them "run free" in our digital environment.

In the Python code below, I'm essentially doing the same thing I did in the JavaScript code block, with slightly different syntax. Instead of creating a standalone actor named 'ian', I first had to create an Actor "class" which is essentially the building blocks for any future actors I create.

Then, I can create an "ian" actor with several unique properties, but it also has access to the action function we created in the Actor class, even though I don't explicitly give it to him. In theory, this allows Sir Ian to say his line whenever he wants. He has his own power!

class Actor:    
  def action(self):
    print(self.line)

ian = Actor()
ian.name = "Sir Ian McKellen"
ian.role = "Gandalf"
ian.line = "WIZARD, YOU SHALL NOT PASS!"

# prints 'WIZARD, YOU SHALL NOT PASS!'
ian.action();

Funnily enough, Python can also serve as a scripting language as well, but we'll avoid diving deep into that today. Just know that Python can tell actors like Sir Ian to do something too, but JavaScript is considered the industry standard for scripting languages.

How they're used in the real world

In so many words, JavaScript is the master of the web. It practically tells everything you interact with online to "do something". The browser you're using right now has a JavaScript engine that tells your computer to render these words on the screen. When you leave a comment or a "like" when you're done reading this, you're telling this page to make a record of your interaction.

In fact, if you're using Firefox or Chrome, you can used Command + Option + I to open up a window where you can play with live JavaScript. It's quite literally everywhere.

The web is a giant latticework of users and programs just telling each other what to do: give me this video, post this message, save this playlist.

But what is that video, message, or playlist made of? Well, foundationally, it's just an object. So, it's very possible that you could be using JavaScript to do something and that "thing" could be an object made with Python.

Because languages like Python can be used for modeling objects so well, it should come as no surprise that the applications for Python are almost limitless, which makes a great language to learn if you're just starting out or if you're a team of data scientists trying to model the human brain for an artificial intelligence project (that will be next week's blog post).

Conclusion

The biggest obstacle in learning how to do something is sometimes the learning itself. Meaning, you can only learn so much before it becomes time to do something with what you've learned.

It's my hope that after learning a little about the differences (and similarities) of JavaScript and Python, you'll feel more empowered to start typing in some code yourself. Again, which language you choose doesn't really matter, so choose one and let it rip.

Using ES6 Destructuring in JavaScript

Mac Little — Mon, 18 May 2020 00:13:38 +0000

Although the sixth edition of ECMAScript (colloquially known as ES6) was released almost five years ago, there are still a lot of features that new developers like me can implement beyond the simple reason to "get with the times".

ES6 features like destructuring not only make it easier to extract data from complex data types, they also makes our code easier to read and make more sense to the outside world.

In this post I'll be walking you thorough a few ways to use destructuring on objects and arrays in your code.

Destructuring Objects

Keeping with our basketball theme from a few weeks ago, let's say we have an object that contains the starting five for the New Orleans Pelicans.

const pelicans = {
pg: 'Jrue Holiday',
sg: 'Lonzo Ball',
sf: 'Brandon Ingram',
pf: 'Zion Williamson',
c: 'Derrick Favors'
};

Now, if we wanted to isolate each player into their own variable, we could create a variable for each player then assign it to the value of the pelicans object like so:

let pg = pelicans.pg;
let sg = pelicans.sg;
let sf = pelicans.sf;

However, writing out each variable declaration and assignment can get pretty boring and repetitive. With destructuring, we can create something that looks like a temporary object that holds all of the keys we'd like to create new variables from, then assign it to the object we're trying to extract from.

Once we console.log one of those newly created variables, we see that it contains the value from the object.

const {pg, sg, sf, pf, c} = pelicans;
console.log(pg); // prints Lonzo Ball to the console

But as most modern basketball fans know, there is a growing trend around the idea of "postionless" basketball, so you might have heard how a point guard might play the "one" or the small-forward is a "three".

So let's use these naming conventions instead! Destructuring also allows us to do that by listing the keys and then pairing them with our new variable names.

const {pg: one, sg: two, sf: three, pf: four, c: five} = pelicans;
console.log(four); // prints 'Zion Williamson' to the console

Passing in an Object as a Function's Parameters

It's very common to take in an object within your function and then do something with only a few of the values you actually need. For example, let's create a simple slamDunk function that takes in a player object and then prints something to the console with their name.

const slamDunk = (playerObj) => {
  console.log(playerObj.first + " " + playerObj.last + " with the slam!");
}

let zion = {
  first: "Zion",
  last: "Williamson",
  team: "Pelicans"
};

This will work, but again, using playerObj.first and then playerObj.last with the additional spaces in-between is a little messy. Destructuring can help us here too, in a couple of ways.

First, we can use assignment destructuring immediately within our function to grab the values we need.

const slamDunk = (playerObj) => {
  const {first, last} = playerObj;
  console.log(first + " " + last + " with the slam!");
}

Looks better, but believe it our not, with the help of template literals (another cool ES6 feature) and backticks within our console.log we can still optimize the function by destructuring our object before it even reaches our function body.

const slamDunk = ({first, last}) => {

  console.log(`${first} ${last} with the slam!`);
}

slamDunk(zion); // prints 'Zion Williamson with the slam!' to the console

You'll notice that our code even recognizes the spaces between the first, last, and the rest of our statement. This kind of formatting makes our rather long console.log into a simple, dynamic string.

Destructuring Arrays

Similarly to object destructuing, you can destruct arrays by declaring your variable names inside brackets (for arrays we use square brackets) then "assigning" to the array you'd like to pull your values from.

For instance, let's say you were only interested in the first three values from whatever array you are being given. You could create a bunch of variables like this:

const array = [1, 2, 3, 4, 5];
const first = array[0];
const second = array[1];
const third = array[2];

Or you can use destructuring to do a lot of that work for you.

const [first,second] = [1, 2, 3, 4, 5];
console.log(first); // prints 1 to the console
console.log(second); // prints 2 to the console

Since arrays are ordered, you can also use commas to "skip" over elements that you don't want to extract. In this example, I'm grabbing the first element in the array. After adding four commas, I'm grabbing the fifth element as well.

const [first,,,,fifth] = [1, 2, 3, 4, 5];
console.log(fifth); // prints 5 to the console

Conclusion

Since complex data types like objects and arrays are so prevalent in our daily life as programmers, it only makes sense that we do everything we can to make that process as simple as possible. As I mentioned last week, we should always be striving to remove complexity from our programs whenever we can.

With destructuring, we remove complexity by quickly extracting the data we need in a simple, logical syntax that makes sense to others reading our code.

If you'd like to learn more things you can do with destructuring, I'd recommend you check out this post from Nick Fitzgerald at Mozilla back when ES6 was first released.

In the meantime, give destructuring a try in your code. It's definitely a little confusing to start, but like anything else, a little practice goes a long way.

Applying Object Oriented Programming Theory in JavaScript

Mac Little — Mon, 11 May 2020 07:35:41 +0000

Let's just start here: this is not a post that will have any part of the "Is JavaScript a 'true' Object Oriented Programming Language?" discourse.

While certainly fascinating, as a relatively new programmer myself, it can be somewhat disorientating trying to discern what Object Oriented Programming even is without accidentally stumbling upon someone's manifesto.

Thus, I've decided to write a quick overview of three key concepts of Object Oriented Programming and then show you how they can be used in JavaScript as you build your programs.

Quick Intro into OOP

What is OOP? Well, not to give a total cop-out, but it's programming oriented around objects. In JavaScript, everything is an object (seriously, everything). Exploring that concept would take a few more blog posts, so to keep on track, let's simplify it a bit.

Let's pretend that we're creating a software program that simulates how cars drive on the highway. Why? Well, in another psuedo-cop-out, cars are actually a great, tried and true example of using objects in code, and they'll be an even greater example as we explore more concepts around OOP.

Encapsulation

The first basic concept of OOP is Encapsulation. In very simple terms, encapsulation is the practice of building objects (in our example, cars) that are self-contained.

const Car = {
 fourWheels: true,
  windows: true,
  powerSource: "engine",
  drive: function() {
    console.log("Put your foot on the pedal")
  },
  park: function() {
    console.log("Don't lock the keys in the car!")
  }
};

So here we have a Car object that we will model all of our cars off with some more specific properties later. However, there are a few properties that we know almost every car has: four wheels, windows, and a power source that is an engine. Plus, no matter what make or model a car is, it has a few basic methods that it can do. In this example we have a drive key and a park key, which both contain functions as values.

Do we drive cars by asking someone else for instructions every time before we get behind the wheel? No. Do we just assume that we have four tires every day? Yes. We know how to drive and we know for a fact that these are components of our car because they've been designed that way. And they've been designed that way because that limits our ability to make mistakes or let outside variables impact how our cars function.

This is where encapsulation helps us.

If we had to re-learn how to park every day by taking someone's instructions or install our own tires, we'd probably make some errors. Encapsulation solves for this by giving our objects some fundamental attributes.

Abstraction

Abstraction is very similar to encapsulation. Essentially, we want to make our objects and their methods as simple as possible. If your car battery dies, you should just be able to install a new one and keep going. A more extreme example could be driving itself. Distracted driving can lead to some serious mistakes, so it's imperative that we give drivers as little to focus on as possible. Just keep your eyes on the road, feet near the break, and hand on the steering wheel.

The same can be said for objects in our code, we want to reduce complexity and dependencies on other things. Ideally, we can use cruise control more often than not.

Inheritance

Does everyone just drive the same car? Of course not! But does everyone's car have a common set of properties and methods? They sure do.

This is our third concept in OOP, which is Inheritance. A highway during rush hour is full of different cars, so let's create some with code. For JavaScript we create cars by referring to our original Car function and then we can make any custom specifications from there.

const Jeep = Object.create(Car);

const Honda = Object.create(Car);

const Chevy = Object.create(Car);

What's great about Inheritance is that it is not a one-size fits all approach. Want to tint your windows? Go ahead! Even if your car comes in blue, you can paint it red. Even as you're making those changes, your car is still retaining those basic properties and methods we named earlier.

When we use Inheritance, we make the process of making new cars flexible, but still efficient. The same should be done with our programs. Objects will and should share properties and methods, so find ways to build them that way ahead of time.

Conclusion

As I mentioned in the opening, Object Oriented Programming is quite the buzzword. And with buzzwords come reactions, good or bad. The important thing to note is that learning "what" a concept is doesn't lead to some idealogical transformation (at least not initially, in my limited experience).

Instead, learning these principles just gives you more exposure to ideas that you can try to implement for yourself down the road.

Building Binary Search Trees with JavaScript

Mac Little — Mon, 04 May 2020 04:41:16 +0000

What are Binary Search Trees?

Binary Search Trees are a node-based data structure that we use in computer science to organize data. Each node can have up to two children nodes.

As we add nodes to our tree, there are only two places that node can go: to the left or the right of the root or parent node. If the value of the incoming node is less than the parent node, it will go to the left. If the value of the incoming node is greater than the parent node, it will go to the right.

In general, all Binary Search Trees are built with three methods:

Insert - which adds a value to our tree
Contains - which checks if a value is present in our tree
depthFirstLog - which takes a function and calls that function and executes it on each value within the tree

Today we'll build our own Binary Search Tree with JavaScript objects that include all three methods above as functions. But first, we need to create our node constructor function.

Build our BST node constructor

Since a BST is made up of nodes, we need to create a node constructor function. Just to bring a little life to this example, I'm going to create a BST that will take in a few players from my hometown Atlanta Hawks and compare their Player Efficiency Rating to the league average PER of 15.


const BinarySearchTree = function(playerObj) {
  // creating a node that will be an object
  let node = Object.create(BinarySearchTree.prototype)
  // creating a name property that takes the name of the player and assigns it to the node
  node.name = playerObj.name
  // creating a value property that takes the PER of the player and assigns it to the node
  node.value = playerObj.per
  // creating a left and right property that are undefinded
  node.left = undefined;
  node.right = undefined;

  return node;
};

Now this code is ready to take our first "player" object the league average parent node that has a PER of 15.

const leagueAvg = {
  name: "League Avg",
  per: 15.00
};

const hawksBST = BinarySearchTree(leagueAvg);

So when we call our BinarySearchTree function with our leagueAvg "player", we can now start adding our other player objects. But first, we need to build our Insert Method.

Building our Insert Method

The first step of our insert method is checking if the input value is greater than or equal to the root node. If it's less than, we check the left node to first see if it even exists. If it doesn't, great! We simply turn that playerObj into a node and put it to the left of our root node.

If there is a node already there, we can use recursion to the same evaluation, only this time instead of referring to the parent node at the top of the tree, we're referring to the child node.


BinarySearchTree.prototype.insert = function(playerObj) {
// checking if the input per is less than the node's value
  if(playerObj.per < this.value) {
  // if true, check if the left property is undefined
    if(!this.left) {
    // if true, create a new node with the playerObj
      this.left = new BinarySearchTree(playerObj);
    // if false, call insert on that playerObj 
    } else {
      this.left.insert(playerObj)
    }
// now checking if the input per is greater than the node's value
  // the rest of the logic is similar to the left's above
  } else if (playerObj.per > this.value) {
    if(!this.right) {
      this.right = new BinarySearchTree(playerObj)
    } else {
      this.right.insert(playerObj);
    }
  }
}

As you'll notice, we use the same exact logic for the right side as well if the input player object has a higher PER than league average.

To see if this works, let's add some objects.

const playerObjs = [{
  name: "Trae Young",
  per: 23.9
},
{
  name: "John Collins",
  per: 23.5
},
{
  name: "Kevin Huerter",
  per: 11.5
},
{
  name: "Deandre Hunter",
  per: 8.6
},
{
  name: "Cam Reddish",
  per: 9.0
}]

After we run our loop over the playerObjs array, we can see that all objects have been turned into nodes within our Binary Search Tree.

// calling insert on each object within our collection
playerObjs.forEach(obj => hawksBST.insert(obj))

BinarySearchTree {
  name: 'League Avg',
  value: 15,
  left: BinarySearchTree {
    name: 'Kevin Huerter',
    value: 11.5,
    left: BinarySearchTree {
      name: 'Deandre Hunter',
      value: 8.6,
      left: undefined,
      right: [BinarySearchTree]
    },
    right: undefined
  },
  right: BinarySearchTree {
    name: 'Trae Young',
    value: 23.9,
    left: BinarySearchTree {
      name: 'John Collins',
      value: 23.5,
      left: undefined,
      right: undefined
    },
    right: undefined
  }
}

Building our Contains Method

Contains is used on a BST to determine if an input value exists as a node within the tree. Like our insert method, we'll start at the top, then work our way down, starting at the left if the input value is less and starting at the right if it's greater. We'll also check if the the right and left nodes are actually defined.

Again, since we've already built our basic contains at the beginning of our function, we can use recursion to call that function again on each node.


BinarySearchTree.prototype.contains = function(playerObj) {
// checking if the value of the parent node is equal to the input value
  if(this.value === playerObj.per) {
    return true;
// now checking if the left node contains the value
  } else if(this.value > playerObj.per && this.left !== undefined) {
    return this.left.contains(playerObj)
// now checking if the right node contains the value
  } else if(this.value < playerObj.per && this.right !== undefined) {
    return this.right.contains(playerObj)
  }
  return false;
}

Building our depthFirstLog Method

depthFirstLog allows us to run a callback function over each node in the tree. So let's make a callback. I actually forgot to include the team name for each node, so let's build a callback that goes through each node and add's a teamName property and gives it a value of "Atlanta Hawks".


cost addTeamName = node => {
  if(node.name !== "League Avg") {
    node.team = "Atlanta Hawks"
  }
}

BinarySearchTree.prototype.depthFirstLog = function(callback) {
  //invoke callback function on this.value
  callback(this);
  //if this.left doesn't exist
  if (this.left) {
    //recursively call .depthFirstLog on this.left & callback
    this.left.depthFirstLog(callback);
  }
  //if this.right doesn't exist
  if (this.right) {
    //recursively call .depthFirstLog on this.right & callback
    this.right.depthFirstLog(callback);
  }
};

hawksBST.depthFirstLog(addTeamName);

You'll notice our callback has one condition: if the name value is not strictly equal to "League Average", we'll update the node. We're only doing this because we don't want our root node to have a team name.

Just like the other methods, we can use recursion to invoke our callback over each node.

BinarySearchTree {
  name: 'League Avg',
  value: 15,
  left: BinarySearchTree {
    name: 'Kevin Huerter',
    value: 11.5,
    left: BinarySearchTree {
      name: 'Deandre Hunter',
      value: 8.6,
      left: undefined,
      right: [BinarySearchTree],
      team: 'Atlanta Hawks'
    },
    right: undefined,
    team: 'Atlanta Hawks'
  },
  right: BinarySearchTree {
    name: 'Trae Young',
    value: 23.9,
    left: BinarySearchTree {
      name: 'John Collins',
      value: 23.5,
      left: undefined,
      right: undefined,
      team: 'Atlanta Hawks'
    },
    right: undefined,
    team: 'Atlanta Hawks'
  }
}

Conclusion

A great component of Binary Search Trees are, well, their binary nature.

After the we establish the root node, the only thing we need to evaluate is our input value relative to the parent node and potentially the the two child nodes after that.

This kind of structure generally delivers on a linear (O(n)) time complexity and, at worst case, a quadratic O(n^2) time complexity in algorithms if the tree is rather long or one-sided.

As you're learning more data structures, I highly recommend using real life data like PER to help your understanding.