DEV Community: Joanna

A deeper dive into Sequelize queries: dynamic field names, the Op object, and raw SQL insertions

Joanna — Sat, 08 Feb 2020 19:22:28 +0000

I recently built a MySQL database using the Sequelize ORM. Some of the querying functions I needed to run required some interesting syntax that I couldn't find specifically outlined in the Sequelize docs, or found the docs a little unclear on, so I thought I'd lay some of them out in this blog in case other people are looking for similar solutions.

Querying with dynamic field names

With Sequelize, you can query for specific field names dynamically. For example, if a user on your app would like to edit a section of their bio, instead of writing one function for every field, or passing back the whole bio along with the updated section every time there's an edit, you can write one function to update any given part of a user's bio in the database.

const updateUserBio = async (req, res) => {
    try {
        const { id } = req.params;
        const { name, bio, link_instagram, photo } = req.body;

        await Show.update(
            { name, bio, link_instagram, photo },
            {
                where: { id: id },
            })
        res.sendStatus(200);
    }
    catch (err) {
        console.log(err);
        res.sendStatus(400);
    }
}

Here, the front end needs to pass back all fields of the record every time I want to update even one section. Instead, I could grab the name of the field from the front end in addition to the new information, and query like so:

const updateUserBio = async (req, res) => {
    try {
        const { id } = req.params;
        const { fieldName, newInfo } = req.body;

        await User.update(
            { [fieldName]: newInfo },
            {
                where: { id },
            })
        res.sendStatus(200);
    }
    catch (err) {
        console.log(err);
        res.sendStatus(400);
    }
}

The above code is less redundant than the first example. It's also more elegant, more flexible, and reusable than creating an update function for each individual field of a given table.

Case-insensitive "contains" querying with the `Op` object

I wanted to allow a user to be able to just search for part of a field value and return a valid, case-insensitive result. (I've since learned about Fuse.js, a really cool library for "fuzzy" querying. But this was how I figured out some version of that before I'd heard of Fuse, and is a reasonable solution if you only want to return exact matches for searches, or don't want to install another dependency into your project.)

Sequelize comes with "operators," which are basically a big handful of comparator functions that live on its Op object. These are useful additions to your where clauses when you're looking for mathematical or comparator operations to run on your data.

One method in particular, Op.like, is really useful in conjunction with a value that looks something like this %{query}%, as below.

const searchBands = async (req, res) => {
    try {
        const { query } = req.params;
        const bands = await User.findAll({
                where: { 
                    { name: { [Op.like]: `%${query}%`} } 
                },
            })
        res.send(bands);
    }
    catch (err) {
        console.log(err);
        res.sendStatus(404)
    }

If I have three bands in my database that have names The Smiths, The Locksmiths, and The Smithies, a user query for "smith" would return all three of those results. Basically, Op.like plus that query field with the % returns results that contain whatever the passed in query is, AND it's case-insensitive. Sweet!

The Op object can be really useful in general. Here's an example of how to use it to inject AND and OR logic into your queries. Below, we're looking for records where either the nickname field includes the query AND the id_type is 2, OR records where the firstName field includes the query string AND the id_type is 2.

const searchBands = async (req, res) => {
    try {
        const { query } = req.params;
        const bands = await User.findAll({
                where: {
                    [Op.or]: [
                        {[Op.and]: [
                            { nickname: { [Op.like]: `%${query}%`} }, 
                            { id_type: 2 }
                        ]},
                        {[Op.and]: [
                            { firstName: { [Op.like]: `%${query}%`} }, 
                            { id_type: 2 }
                        ]}

                    ]
                }
            })
        res.send(bands);
    }
    catch (err) {
        console.log(err);
        res.sendStatus(404)
    }

Use raw SQL queries with your Sequelize

If you're comfortable with raw SQL and are using Sequelize, sometimes it might make the most sense for you to throw a raw SQL query in the mix. This can be done like so:

const { Sequelize } = require('sequelize');

const sequelize = new Sequelize(DB_NAME, DB_USER, DB_PASS, {
  dialect: 'mysql',
  host: DB_HOST,
  timestamps: false,
  pool: {
    max: 3,
    min: 0,
    idle: 10000
  },
});

const getBandFollowers = async (req, res) => {
    try {
        const { id } = req.params;
        const sql = `SELECT * FROM users WHERE id IN (
                        SELECT id_fan FROM fans_bands WHERE id_band = ?)`;
        const followers = await sequelize.query(sql, {
            replacements: [id]
        })
        res.status(200).send(followers);
    }
    catch () {
        res.sendStatus(400);
    }
}

You call the query on the sequelize connection that you've created. Write the raw query and pass it to sequelize.query. If you have replacements to pass in, simply add them as a second argument to the query function in an object with the key of replacements.

An Intro to Using Expo Push Notifications

Joanna — Mon, 03 Feb 2020 00:20:03 +0000

I recently implemented push notifications for a native iOS app built on React Native with Expo and a NodeJS/Express server. Expo's Push Notifications API is very handy, but I was initially a bit confused about how to use this tool on my back end. In this blog, I'll run through my solution to this problem, in the hopes that it might help other folks who want to use push notifications in their mobile applications.

1. Get and store your user's push token

Expo's docs are helpful for this, and they give you a boilerplate function you can use on your front end.

To do this, I first created a file in our client directory called registerForPushNotificationsAsync.js, where I put the following, based off the Expo boilerplate:

import { Notifications } from 'expo';
import * as Permissions from 'expo-permissions';

export default async function registerForPushNotificationsAsync() {
  try {
    const { status } = await Permissions.askAsync(Permissions.NOTIFICATIONS);
    // Stop here if the user did not grant permissions
    if (status !== 'granted') {
      return null;
    }
    // Get the token that identifies this device
    const token = await Notifications.getExpoPushTokenAsync();
    return token; 
  }
  catch(err) {
    console.log(err);
  }
}

Permissions.askAync() checks to see if the user has granted permission for notifications on their phone from your app. If the status is not granted, we escape the function. Otherwise, we ask the Expo API for a unique token. The token should look something like this:

ExponentPushToken[xxxxxxxxxxxxxxxxxxxxxx]

In my SignUp component in the React Native front end, I call registerForPushNotificationsAsync in the below function, googleSignUp, when a user clicks a "sign up" button.

// ...
import registerforPushNotificationsAsync from '../expoPushFunctions/registerForPushNotificationsAsync';
// ...
  const googleSignUp = async () => {
    try {
       // Get user Google auth info and add them to the database .
       // ...
      .then(async () => {
        // call the Expo function we created above
        const expoPushToken = await registerforPushNotificationsAsync();
        return expoPushToken
      })
      // and add the returned token to the user's record in the database
      .then(expoPushToken => {
        axios.patch(`${URL}/users/${user.email}/push`, {
          expoPushToken
        })
      })
      .catch(error => console.log(error));
    } catch(error) {console.log(error)}
  }
// ...

So whenever a user signs up (and has allowed notifications from my app), they receive a unique Expo token, which is stored in their personal record in the database.

2. Send notifications from back end

I want to send the user notifications whenever a band they follow creates a new show.

Build the Expo API call

First, I set up the function that will make the Expo Push Notification API call. I made the file pushNotifications.js with the following function, also based on a boilerplate function from Expo:

const { Expo } = require('expo-server-sdk');
// Create a new Expo client
const expo = new Expo();
const sendNotifications = async (pushTokens, title, body) => {
    try {
        // Create the messages that you want to send to clents
        let messages = [];
        for (let pushToken of pushTokens) {
          // Check that all your push tokens appear to be valid Expo push tokens
          if (!Expo.isExpoPushToken(pushToken)) {
            console.error(`Push token ${pushToken} is not a valid Expo push token`);
            continue;
          }
          // Construct a message
          const message = {
            to: pushToken,
            sound: 'default',
            title,
            body
          }
          messages.push(message)
        }
        // Batching nofications
        let chunks = expo.chunkPushNotifications(messages);
        let tickets = [];
        (async () => {
          for (let chunk of chunks) {
            try {
              let ticketChunk = await expo.sendPushNotificationsAsync(chunk);
              console.log(ticketChunk);
              tickets.push(...ticketChunk);
            } catch (error) {
              console.error(error);
            }
          }
        })();
    }
  }
      catch(err) {
          console.log(err);
      }
}

module.exports = {
    sendNotifications,
    expo
}

This function will be passed a title, body, and array of push tokens. I want to be able to use this function for different types of notifications, which is why I'm going to pass in the title and body of the message dynamically.

The function builds an Expo-compatible message for each user and sends the group of messages out in batches.

Create the route and the querying function

Like I said, every time a musician creates a new show on my app, I want their followers to be notified. So in a createShow function in my database helpers, I added a call to the Expo API through that sendNotifications function.

const createShow = async (req, res) => {
    try {
        let { name, dateTime, venueName, bandName } = req.body;
        // store new show in database
        const show = await Show.create({
           // ...
        })

        // For each band playing the show, send push notifications to followers
        await bandNames.forEach(async (bandName) => {
            // Create push tokens array for band followers
            let pushTokens = [];
            const band = await getRecordByName('band', bandName);

            // Get all followers of a given band
            const sql = `SELECT * FROM users WHERE id IN (
                SELECT id_fan FROM fans_bands WHERE id_band = ?)`;
            const followers = await sequelize.query(sql, {
                replacements: [band.id]
            })
            // Push their tokens to the pushTokens array
            followers.forEach(follower => {
                pushTokens.push(follower.expoPushToken)
            })
            // Construct title and body for message
            const title = `New show from ${band.name}!`;
            const body = 'Open Dive for more info.';
            await sendNotifications(pushTokens, title, body);
        })
        res.sendStatus(201);
    }
    catch (err) {
        console.log(err);
        res.sendStatus(400);
    }
}

I've created an account in the app and followed a band to test this functionality out. With the app in the background on my phone, when I use Postman to create a sample show, I get the following result:

And that's it! This is just one example of how you can use Expo's push notifications API, and I hope seeing this solution has helped make that process more clear.

Eager Loading: Fetching Associated Data with Sequelize

Joanna — Mon, 27 Jan 2020 00:16:26 +0000

I just built a database using Sequelize for the first time. I had to solve the problem of not just fetching one record from the database, but much of its associated data as well. My first attempt was long and unwieldy, and involved nested Promises, and mapping, and manually adding properties to the AJAX response object -- it was kind of a mess! And...it didn't work.

I spent about an hour Googling around the topic of eager loading, but not quite landing on it. It's amazing how much a vocabulary limitation can hinder efficient research. Once eager loading entered my scope, it was smooth sailing. (Okay, not really-- but it did make my life a lot easier).

Do not fear the jargon

Eager loading in Sequelize is similar to a JOIN in raw SQL queries. It just means that with a few extra lines of code, you can fetch a given table AND its associated data. Per the Sequelize docs, it basically just means joining two tables.

The problem

So for our schema, we have, among other things, a Show model. Each show has a few associations, or relationships: one Venue where the show takes place, and potentially many Bands who are playing at the show:

A show takes place at one venue, and a venue can have many shows (one to many
A show can have several bands, and a band can play many shows (many to many)

The task: using the Sequelize ORM, fetch the info for an individual show, plus its associated venue and bands.

The associations

Venues and shows (one-to-many)

Show.belongsTo(Venue, { foreignKey: { name: 'id_venue', allowNull: false } });
Venue.hasMany(Show, { foreignKey: { name: 'id_venue', allowNull: false } });

I wanted to be able to query for a venue and its associated shows, as well as query a show for its associated venue, so I needed to declare the relationship in both directions. Initially, I didn't not include the Venue.hasMany(Show), and thus, when I attempted a search for a venue and its associated shows, I got the error show is not associated to venue!

So if you want to query bidirectionally, declare the associations bidirectionally.

Shows and bands (many-to-many)

Show.belongsToMany(User, { as: 'bands', through: ShowBand, foreignKey: { name: 'id_show', allowNull: false } });
User.belongsToMany(Show, { through: ShowBand, foreignKey: { name: 'id_band', allowNull: false } });

When declaring many-to-many associations, Sequelize requires a through parameter, in which you pass in the name of the join table that represents that many-to-many relationship. (You can create your own model, as I did, but if you don't, Sequelize will auto-generate that join table for you-- but you still have to give it a name in through).

I also wanted to declare an alias for how the User model actually related to the Show table. My User table contains two types: Fans and Bands. And I wanted to make it clear that only the users who were of type Band belonged to Shows in this particular way. So with as, I gave User an alias of bands.

Again, you'll want to declare the relationship in both directions.

The queries

Retrieve a single show and its associated bands and venue

// get detailed info for single show
const getSingleShow = async (req, res) => {
    try {
        const { id } = req.params;
        const show = await Show.findOne({
            where: {
                id
            },
            include: [
                { model: User, as: 'bands', attributes: ['id', 'name'] },
                { model: Venue, attributes: ['name'] },
            ]
        })
        res.send(show);
    }
    catch () {
        res.sendStatus(400);
    }
}

The function above is for retrieving information about a show given its id, passed in through the endpoint parameters.

The include is the important part of eager loading. We find the given show, then with include, we can request any associated info we want. (Note that we must specify the alias that we assigned the particular related record in our association declaration.)

We can also filter out what's returned with the attributes keyword. In this case, I'm just returned the name and id of the venue and each band.

My returned object looks something like this:

{
     "id": 4,
    "name": "cool show",
    "date": "7/20",
    "time": "9:00PM",
    "bands": [
        {
            "id": 5,
            "name": "The Yeahs",
        },
        {
            "id": 6,
            "name": "Shark Attack",
        }
    ],
    "venue": {
        "id": 1,
        "name": "gasa"
}

You can see that the show bands are returned as an array with a plural name, because there could be many bands that belong to a show. Venue, on the other hand, is a singular object, because a show can only have one venue.

Similarly, we can perform a query for a venue and its associated shows, and nest another include to get back those shows' associated bands.

Here's the query:

const getSingleVenue = async (req, res) => {
    try {
        const { id } = req.params;
        const venue = await Venue.findOne({
            where: {
                id
            },
            attributes: ['id', 'name'],
            include: [
                { model: Show, 
                    include: [
                        { model: User, as: 'bands', attributes: ['id', 'name'] }
                    ]
                }
            ]
        })
        res.send(venue);
    }
    catch() {
        res.sendStatus(400);
    }
}

Here's the result:

{
    {
        "id": 1,
        "name": "gasa",
        "shows": [
            {
                "id": 1,
                "name": "cool show",
                "date": "7/20",
                "time": "9:00PM",
                "bands": [
                    {
                        "id": 1,
                        "name": "The Yeahs",
                    }
                ]
            },
            {
                "id": 2,
                "name": "another cool show",
                "date": "7/20",
                "time": "9:00PM",
                "bands": [
                    {
                        "id": 1,
                        "name": "The Yeahs",
                    },
                    {
                        "id": 2,
                        "name": "Shark Attack",
                    }
                ]
            }
        ]
    }
}

For some perspective, here's the raw SQL query that is performed from the getSingleVenue Sequelize query above:

SELECT `venue`.`id`, `venue`.`name`, `shows`.`id` AS `shows.id`, `shows`.`name` AS `shows.name`, `shows`.`date` AS `shows.date`, `shows`.`time` AS `shows.time`, `shows`.`photo` AS `shows.photo`, `shows`.`description` AS `shows.description`, `shows`.`createdAt` AS `shows.createdAt`, `shows`.`updatedAt` AS `shows.updatedAt`, `shows`.`id_venue` AS `shows.id_venue`, `shows->bands`.`id` AS `shows.bands.id`, `shows->bands`.`name` AS `shows.bands.name`, `shows->bands->shows_band`.`createdAt` AS `shows.bands.shows_band.createdAt`, `shows->bands->shows_band`.`updatedAt` AS `shows.bands.shows_band.updatedAt`, `shows->bands->shows_band`.`id_show` AS `shows.bands.shows_band.id_show`, `shows->bands->shows_band`.`id_band` AS `shows.bands.shows_band.id_band` FROM `venues` AS `venue` LEFT OUTER JOIN `shows` AS `shows` ON `venue`.`id` = `shows`.`id_venue` LEFT OUTER JOIN ( `shows_bands` AS `shows->bands->shows_band` INNER JOIN `users` AS `shows->bands` ON `shows->bands`.`id` = `shows->bands->shows_band`.`id_band`) ON `shows`.`id` = `shows->bands->shows_band`.`id_show` WHERE `venue`.`id` = '1';

Nuts, huh? So, if your schema features a number of associations and you want to perform efficient but complicated join queries, an ORM like Sequelize is a great way to make that happen.

An Intro to Dependencies and Package Managers (NodeJS style)

Joanna — Mon, 20 Jan 2020 00:35:53 +0000

In this post, I'm going to give a brief intro to package managers, dependencies, and semantic versioning.

What are dependencies?

Any given development project will likely have numerous dependencies. "Dependency" is just a word to denote a framework or a library that someone else has written to make your life easier. Thanks, dependency authors! Dependencies allow us to write less code and spend less time figuring out logic from scratch. Sometimes you will hear dependencies referred to as packages.

Dependency hell

A given dependency itself could have a bunch of its own dependencies. For example, say I have a project with ExpressJS as its only first-level dependency. The package-lock.json file, which keeps track of the dependencies of a given package, is 375 lines long. My node_modules file, which is where all those sublevel dependencies are installed, has 49 modules added to it. This is just on account of installing one dependency.

Imagine if you had to install Express, plus all of its dependencies, and then all the dependencies of those dependencies... No thanks. Dependency hell is what that is!

Enter package managers.

Package managers

Package managers are tools (written and maintained by developers) that automate the task of installing and updating the dependencies of our project.

When we use a package manager (like npm or yarn) to install a package in our NodeJS project, the given package is added to the dependencies of our package.json file -- and all of that dependency's dependencies are also installed. You can find all of secondary dependencies in your node_modules folder, as well as in the package-lock.json or yarn.lock file, depending on which package manager you're using.

(Package managers pull dependencies from package registries. npm has its own registry that is actually the default registry for yarn as well. Github released their own registry in mid-2019.)

Package versions and team collaboration

If we're using Github to work on a team project, conventionally, we keep the node_modules directory in our .gitignore file. This means that anyone who wants to work on the project must run npm install or yarn after cloning from Github to install the relevant dependencies.

Here, some potential problems come into play with versioning. Any given package has a version number that looks something like this: 1.2.3. Each part of that number represents the major, minor, and patch version of a package, respectively.

Semantic versioning is the name of an agreed-upon system that helps developers decide what kind of new version they'll be implementing with a given change: i.e. will it be a major, minor, or patch release? (Semver.org has some detailed info on how developers should distinguish between the versions, and a thorough explanation of semantic versioning theory.)

Additionally: in your package.json file, the version number by a given dependency can be preceded by a carat (^) or a tilde (~). ~1.2.3 means to install only the newest patch version of a package, so up to 1.2.9. ^1.2.3 means to install the newest minor or patch version, so up to 1.9.9. A normal install will automatically add a carat to this version. You can remove this carat to indicate that the install should exclusively download the curently listed version.

So ideally, developers working on a project will be using the same version of a package, because, depending on whether it's a major, minor, or patch update, certain parts of the dependencies could behave in new ways that might break some code.

npm & yarn

For a while, npm was the de facto package manager for NodeJS projects, and it's still many developers' go-to as well as the default for Node. However, prior to 2016, users were having issues maintaining consistent semantic versioning across teams.

In 2016, Facebook released yarn, which introduced a yarn.lock file. This promised to solve the issue of different developers installing different versions of a package in the same project, leading to bugs. npm soon followed with its own lock file, package-lock.json.

(There is still some controversy and confusion around how lock files do and should work, but that's beyond the scope of this article. This article is a good start for learning more.)

Leading up to 2016, npm dealt with a few major issues, and if you had asked me in 2016 which package manager I preferred, I would have probably said yarn. Since then, however, it seems like npm has made major upgrades to catch up to yarn and make up for the issues it created in the past.

And while npm and yarn appear to be the main players out there for JavaScript package management, they're not the only options. pnpm is a newer package manager. If you are developing multiple projects that all use the same version of a particular package, npm and yarn would save the whole package onto your disk for each project. pnpm saves room on your development drive by only saving a package once and using a "hard link" to refer to it in whatever project's node_modules file it needs to be in. Check out this blog for more info about how that works.

A Case for Unit Testing and an Intro to Jest

Joanna — Mon, 13 Jan 2020 04:46:10 +0000

If you're anything like me, when faced with a deadline, you want to jump headfirst into actual coding. Sure, maybe you'll do a little bit of wireframing, or sketch out your API endpoints, but the faster you get to coding, the better -- you've got a lot to do!

In this post, I'm going to try to make the case that testing is not only worth your time, but will ultimately save you lots of heartache and struggle down the road, because it will force you to thoroughly organize your program by breaking up large tasks into smaller pieces.

I'll also run through a short example of how to write unit tests using the Jest framework.

What is testing, and why unit test?

In the context of coding, unit testing involves breaking down the functionality of a program into its most tiny and digestible units, and writing tests that verify that each unit of your code is performing as expected.

At first, it may not seem obvious that testing is useful. After all, doesn't it mean you end up writing more code?

That's true. It takes time. But--

1. It doubles as documentation.

Test framework syntax is pretty similar to English -- closer than your vanilla programming language, at least. Because of this, test functions are almost a literal explanation of what a given function should do! Pretty handy for your future self and other programmers reading your code.

2. You can't always predict the complexity that can sneak up on you.

As programmers, we should remain humble, and assume that we'll sometimes get confused on the path towards our goal.

Code can start off digestible, but it can easily grow in complexity. We should use whatever tools we can to avoid being overwhelmed by that complexity. Testing is one such tool.

3. Unit testing forces you to modularize your code and organize your thoughts.

Ideally, testing will result in you breaking down your program into the smallest possible units, and really digging in to what you expect each unit to do. Not only will this make your code less brittle, but it will force you to have a deep understanding of how each section of your code works, and how all of it works together.

Testing frameworks

You technically don't need a framework to run tests, but they make the process super convenient. There are a several reliable testing frameworks out there. I'm going to work with Jest for this example, which is a tool that comes with the Create-React-App boilerplate. It has its own built-in assertion, spy, stub, and mock libraries, and also allows you to easily test front end components.

The basics of Jest

Setup and syntax

You'll need a package.json file. (If you don't have one, run npm init -y from your terminal.)

Run npm install --save-dev jest and add jest to the test script in your package.json. From here on out, running npm test will activate your Jest test suite.

"scripts": {
    "test": "jest"
  },
  "jest": {
    "collectCoverage": true,
    "coverageReporters": [
      "html"
    ]
  }

If you've installed a create-react-app boilerplate, Jest should already be there in your test script for you.

Create a file where you'll write and export the function you're testing. Create another file for your tests. Require the function you want to test in your test file.

// mySweetFunction.js
const mySweetFunction = () => {
  const somethingSweet = 'sweet';
  return somethingSweet;
}

module.exports = mySweetFunction;

// mySweetFunction.test.js
const mySweetFunction = require('./mySweetFunction'); 

describe('my sweet function', () => {

  test('it should return something sweet', () => {
    expect(mySweetFunction()).toBe('sweet');
  });

  test('it should not return something sour', () => {
    expect(mySweetFunction()).not.toBe('sour');
  })
})

describe() groups multiple related tests together. test() calls each individual test. Both describe() and test() take two arguments:

A string that describes what the particular feature of the function is, or what function we're describing.
An anonymous test function

A common way to write a test with Jest is to use the expect() keyword with a matcher to compare values. In the example above, toBe() and not.toBe() are matchers. (There are many matchers to suit your needs. Check them out here.)

For the love of MPJ, write unit tests!

This is a super brief intro to test writing and why you should invest your time in it. The example I've given here is a small one, and I wouldn't necessarily recommend writing a test suite for a very small program. But for any robust project with multiple moving parts, you should seriously consider writing tests before you write any other code.

Like flossing your teeth, writing unit tests doesn't provide much instant gratification, but it can save you a lot of pain down the road.

A Beginner's Guide to Async/Await

Joanna — Sun, 15 Dec 2019 21:54:05 +0000

Async/await was rolled out with ECMAScript 2017, and enables our asynchronous code to flow even more like synchronous code. It's basically syntactic sugar for Promises, so like Promises, it helps us avoid writing deep chains of nested callbacks, and is arguably even more readable than regular Promises.

Syntax

To declare an async function, put async at the beginning of your function declaration.

Like so:

async function greeting(word) {
    return word;
}

Using the async keyword lets the interpreter know that the function should evaluate to a Promise instead of directly returning a value.

So the function above is effectively the same as:

function greeting(word) {
   return Promise.resolve(word);
}

In the second function, we are explicitly stating that this function returns a Promise. In the first one, the async keyword is doing that implicitly for us.

Let's resolve it

Technically, we can call an async function just like a normal Promise, using a .then() statement to make sure it evaluates to a value, and not just a Promise object.

async function greeting(word) {
    return word;
}

greeting('Hi'); // Promise { ‘Hi’ } <-- evaluates to a Promise object

greeting('Hey')
.then(word => console.log(word)); // ‘Hey’ <-- evaluates to a fulfilled Promise

If we call greeting by itself, then it’s going to evaluate to a pending Promise object, so we could use .then() to make sure it the Promise is fulfilled.

But (a)wait!

What makes an async function so exciting is the possibility of using the await keyword. When we put await in front of an expression in our async function, we’re telling the interpreter, hey, this expression returns a Promise, so wait-- pause code execution here until the function that follows await is finished running, and then resolve that Promise!

Let's try it out

async function makeCall() {
   try {
      const response = await axios.get('https://somewebsite.com');
      console.log(response.data);
   } catch(error) {
      console.log(error);
   }
};

So we’ve got an async function makeCall(). Our axios GET request is being called with the await keyword, which means that nothing happens with the rest of makeCall() until the response is received from the axios request.

The axios library is also built on Promises-- axios requests return Promises. But if a function does not inherently return a Promise, await turns it into one that does.

The await keyword basically injects the resolve of a Promise that would otherwise need to be finished/fulfilled with a .then().

Here, we’re storing that resolve in a variable because we want to do something with it-- namely, grab the data from that response object and then console log it.

(We handle our errors by placing the body of our main call in a try block, and follow that up with a catch block.)

Pretty cool! And a bit easier to read than this:

function makeCall() {
    return axios.get('https://somewebsite.com')
        .then((response) => {
        console.log(response)
    }).catch((error) => {
        console.log(error)
    });
}

Avoid chaining

With normal Promises, when we have multiple Promises that need to be resolved, our code could look something like this:

function makeThreeCalls() {
    return axios.get('https://someurl.com')
    .then(() => {
        axios.get('https://anotherurl.com')
    }).then(() => {
        axios.get('https://yetanotherurl.com')
    }).catch((error) => {
        console.log(error);
    })
}

This is definitely better than callback hell. But we're still left with this chain of .then()s, and each of those .then()s have their own arrow function.

Using async/await makes our code even more readable, especially when multiple calls are involved.

async function makeThreeCalls() {
    const firstCall = await axios.get('https://someurl.com');
    const secondCall = await axios.get('https://anotherurl.com');
    const thirdCall = await axios.get('https://yetanotherurl.com');
    console.log(`${firstCall}, ${secondCall}, ${thirdCall}`)
}

This is an async function with three await statements in one block of code. It just reads a little more like synchronous code, doesn't it?

We've got three axios requests that are preceded by the await keyword, which means they’re going to be resolved Promises. Our interpreter waits for one request to be done before it invokes the next.

Promise.all()

We can speed this process up the same way we would with normal Promises. Instead of running the functions one by one, waiting for one function to resolve before we call the next, we can run them in parallel. We do this by calling them with Promise.all().

async function makeThreeCalls() {
    const [ firstCall, secondCall, thirdCall ] = Promise.all([
        await axios.get('https://someurl.com'), 
        await axios.get('https://anotherurl.com'),
        await axios.get('https://yetanotherurl.com')
    ]);
    console.log(`${firstCall}, ${secondCall}, ${thirdCall}`)
}

This saves a lot of time.

~~~~

I hope this was a helpful introduction to async/await, which is just syntactic sugar on top of Promises. It can make your code even more intuitive and easier to read. It allows us to write asynchronous code that reads more like synchronous code, and helps us avoid the .then() chains that are still necessary with normal Promises.

Untangling the JavaScript Event Loop

Joanna — Sat, 07 Dec 2019 19:53:23 +0000

JavaScript is single-threaded AND it's used asynchronously. This idea used to boggle my mind...until I learned about browser event loops.

JavaScript under the hood

First, we should understand the context in which our code is executed, or the runtime environment. You can think of this as the abstract container where the browser, the JS engine, web APIs, and your code all interact.

So while it's true that JavaScript is single-threaded, and that the engine interprets it line by line, there are other tools at play, and these tools help make using JS asynchronously possible. The event loop is simply another tool in this environment.

So what's the event loop?

Broadly, the event loop is a process the browser undergoes whenever it’s sent asynchronous code. It handles the timing of the execution of various chunks of the program.

To do that, and to see what needs to be done when, it monitors the function callstack and the callback queue. Whenever it's time to execute some code in the queue, the browser calls upon a JavaScript engine to perform that execution.

Event listener hash

One major part of the event loop is the event listener hash. This is basically a storage object for asynchronous functions to go after they've been parsed by the interpreter. There, they wait to be invoked. How long? Depends. But these functions are not touched until after the interpreter is finished running through the entire code body.

Callback queue

The callback queue is another key part of the event loop. Functions waiting in the event hash are eventually sent to the queue if its associated event has happened (time passing for setTimeout, or a click event, or a server response for an AJAX call, etc)...but again, only after the interpreter is done running through the code.

Tick, tick, tick

Each event loop, or tick, has three steps.

First, the event loop performs some internal upkeep, which could be something like removing expired events from the events listener hash.
If and only if the callstack is empty, it moves the appropriate functions from the events listener hash to the callback queue.
The final step is to dequeue the first function from the queue and invoke it. And then the loop starts over gain.

The event loop in action

here's some mostly asynchronous code

Let's walk through how the above code would run with the event loop and the queue.

Engine interprets

First, the engine runs through the code line by line. If it sees any asynchronous functions, it passes them off to the event listener hash. In our example, the functions on lines 6, 10, and 13 all are handled asynchronously (by an event click, a setTimeout, and an AJAX call respectively), so they go wait in the hash.

The only function that actually gets invoked by the engine is logMeNow on line 19.

Browser examines hash

Once the engine is done interpreting, the browser can turn its attention to the event listener hash. It moves whatever functions it can to the callback queue (step two in the event loop). For now, this would include the phoneCall from line 9, since it had a wait time of 0 milliseconds.

We’re also gonna hypothetically say a user clicked on the body at this point, so we’ll queue up the function from line 6 too. And let's say we haven’t gotten our AJAX response yet from our request on line 13.

Browser moves to queue

The browser has now added everything to the queue that it needs to, so it can move onto step three of the event loop, which is dequeuing and invoking the function at the front of the queue.

The phoneCall from the setTimeout would be dequeued and invoked, and the click event phoneCall would be pushed to the top of the queue.

Back to the beginning

The loop then starts over with step one, the browser's internal upkeep. This would include removing the setTimeout phoneCall from the hash. (The event click function (lines 5-7) would remain in the hash, though-- click events and similar events remain in the hash throughout the life of a program.)

Voilà!

Hopefully this helped to clear up some confusion you may have had about the event loop. To recap, it's a tool the browser uses to handle asynchronous functions. It does that by storing those async functions in the event listener hash until (1) the interpreter is done running through the code and (2) the callstack is empty. When it's time, it moves functions whose 'events' have occurred from the hash to the queue, where they're invoked one at a time.

An Intro to AJAX and the XMLHttpRequest Object

Joanna — Sun, 01 Dec 2019 01:16:01 +0000

Asynchronous JavaScript & XML (AJAX) is the foundation of every modern web application. There are a handful of methods to make AJAX calls in JavaScript, but in this post, I'm going to cover using the XMLHttpRequest object.

Asynchronous programming

Asynchronous programming refers to a technique of writing code that allows multiple tasks to be performed at once without interrupting code execution. This is highly important to JavaScript development because JS is a single-threaded language, which means it's interpreted line by line, top to bottom.

JavaScript does have some built-in tools to help us write asynchronous code. (setTimeout and setInterval, for example, when executed, pass functions off to the browser to be called at a later time.) Writing our JavaScript with AJAX in mind helps us expand on these tools so we don't have to wait for one line of code to finish before the code continues to execute.

With AJAX, we can build Single Page Applications (SPA) that render dynamically with user input. Personally, I can’t remember the last time I used a webpage that required full reloading of the page any time I wanted to interact with it. Asynchronous programming allows us to interact more fluidly with our digital environment.

It's all about the client and the server

When we talk about AJAX and asynchronous code, we’re usually referring specifically to client-server communication. AJAX helps us write code that allows our app to communicate with a server without interrupting the user’s interaction with our client side, and then potentially update our client interface with any data changes that the server sends back in its response.

The basics of AJAX and XHR

So, how does this happen? Enter the XMLHttpRequest object.

The XHR object is an object found on modern browsers that has a bunch of really useful properties that allow us to interact with server asynchronously.

We can use this XHR object and its methods to, among other things: (1) send requests from our client to the server, (2) check the state of a request, (3) receive a response from the server, and potentially (4) execute some action, depending on the success or failure of a server response.

the XMLHttpRequest object in the browser console

From the image above, you can see it’s got all these neat properties, including some it inherits from its _proto_.

The ones we're going to focus on first are .open() and .send() (which live on the proto). When making an AJAX request with an XHR the fundamental steps are to (1) instantiate the XHR object, (2) open the request, and (3) send the request.

implementing an AJAX API call with an XMLHttpRequest object

Let's dissect this. On line 2, we instantiate the object (pseudoclassically!) with the new keyword. On line 3, we call .open(). Our first parameter there indicates the method (i.e. GET or POST). The second, url, is where we're sending our request. The third parameter is a boolean which tells our code whether or not to run this asynchronously, so we've set ours to true.

Then we use .send() to send off the request!

Line 5 is where the magic happens. .onload() is one of a couple methods on the XHR object that help us implement the asynchronous nature of our call. We can optionally pass in two callback functions, one of which will run in case of response success, the other in case of failure.

In this case, we're only running the success callback if our status code comes back between 200 and 300, which means the request was successful.

calling the AJAX call we created above

And then we can just call our AJAX function like we do in the image above, passing in the method, the url, and whatever callbacks we want.

Hopefully this post took some of the mystery out of AJAX and the XMLHttpRequest object. AJAX queries are vital to modern programming and important to learn how to implement. The XHR object is just one of several ways to make an AJAX call to a server.

Comparing Depth-First and Breadth-First Traversals of Graphs

Joanna — Mon, 25 Nov 2019 01:43:19 +0000

We traverse graphs to retrieve information, modify data, or find a path from one point to another. In this post, I'll cover some basic differences between the two approaches to graph traversal: depth-first and breadth-first.

(This post assumes basic knowledge of the graph data structure. Check out this article for an introduction to graphs.)

The main distinction comes down to whether you follow a path to its end point (go deep), or check out all possible first steps first (go wide/broad).

Cycles

Before we get into traversal methods, we should understand that graphs can be cyclical. In other words, it's possible to follow a path from one node back to itself again! This could create some looping problems.

Sanfoundry.com

For this reason, in our implementations of graph traversal algorithms, we should make sure to keep track of which nodes we've visited and which we haven't.

In JavaScript, one way to do that is to create a visited object, wherewe have keys to represent each node, and values set by default to false. When we visit a node, we simply change that value to true. We can also use a visited array to store the items we've checked out already.

example of using a "visited" object to keep track of visited nodes

Depth-first

If you've iterated through tree structures, you're already familiar with depth-first traversal. With DFS of non-tree graphs, just like with trees, we follow a single line of child nodes until we hit a childless node.

depth-first traversal of a directed graph

For DFS, we can use a stack implementation. When we traverse down a path of children, we add them to the stack as we go along. Once we reach a node with no accessible children, we follow our path backwards until we find a node that has another path extending off of it.

In the image above, we've chosen node A as our starting point. One of A's children is B, so we follow that path. One of B's children is D, so we follow that path. We continue to follow a path of children until we get to C. C has a child (D), but that child has already been visited. So we retrace our steps until we find another viable path.

In this case, D had another child that hadn't been visited yet-- E. Eventually we get back to A, which has two other children besides B. C has already been visited, so we visit G, finally completing the original call to traverse through the children of A.

Here's one possible (non-recursive) JS implementation of DFS using a stack:

Breadth-first

In breadth-first searches, we go broad first. This means that after we examine our first node, we examine all of its immediately neighboring nodes before we go any deeper.

breadth-first traversal of a directed graph

For BFS, we use a queue implementation.

With the above example, that means that we'd first add node A to a queue and check its value. If it's not what we're looking for, we'd pop it off the front of our queue, and add its neighbors (B, C, and G) to our list, changing their values in our visited object to true. B would be the next in line. We check it. If it's not what we want, we pop it off the front of our queue, but not before adding its neighbors (D and E) to the back of our queue.

After taking A and B from front of the queue, C is next in line. Its immediate neighbor is D...but D is already in our list. When D comes up first in line, we'll finally add F to our queue.

Here's a possible implementation of BFS in JavaScript using a queue model.

DFS vs BFS

In general, BFS is best for short searches. You can see that in the above examples, a breadth-first took six steps, while a depth-first search took thirteen.

DFS is good, then, if you're interested in checking out all possible paths from one point to another. The famous N Queens problem is a great example of DFS.

Basically, use DFS if you want to exhaust all possible options, and use BFS if you want to find something as quickly as possible!