Quick Wins with Code: Promises in JavaScript

A quick look at handling asynchronous code in JavaScript.

Photo by Ethan Kent on Unsplash

Like a dog waiting for their human to return, programmers often wait for their code to return something. Perhaps it’s JSON from a REST endpoint you hit from the client. Perhaps it’s a record from a database you queried from the server.

Perhaps it’s the human, coming home with treats.

Thankfully, we can do other stuff while we wait! A program can continue executing other code while requests for external resources continue to sit patiently in the background, stepping out of the way so that other code can continue to run. When the code that was waiting on something finally receives that thing, it can then follow up by doing something that it was holding off on doing until it first got what it needed.

To keep up the dog analogy a little longer — this behavior equates to the idea of a dog waiting for its owner to get home before it is let out to do its “business”. However, while the dog is waiting, it chews up a pillow, runs around the house eight times, and barks for twenty minutes. Those actions weren’t dependent on the human returning, so they just happen. Thankfully, the dog at least knows to hold it in the meantime.

This idea of non-blocking code execution is called asynchronous programming.

In JavaScript, we can handle asynchronous code with something called callback functions (see MDN’s doc on callbacks). Callback functions are great, but they’re not always the tool I want to reach for. There’s another tool. For the types of calls where we are waiting on a resource from an external source, I prefer to use the Promise object.

What is a promise?

MDN’s page on the Promise object nails the definition, so I will defer to them:

The Promise object represents the eventual completion (or failure) of an asynchronous operation, and its resulting value.

A Promise is a JavaScript object that helps us handle the timing of asynchronous operations. We can wrap the code we want to run asynchronously in a Promise, which will help us detect when that operation has successfully (or unsuccessfully) completed. We can then trigger follow up code that depended first on a promise fulfillment, or that handles a promise rejection.

Since I started learning JavaScript, I have worked with two prevailing implementations for utilizing promises. They are promise chaining with .then(), and async await.

People seem to have strong feelings about which one is better.

Below are code examples for the same bit of logic written out twice, showing the use of .then() in the first, and the use of async await after that. They both are using a node.js implementation of the fetch() API, which returns a promise (here’s MDN’s page on the Fetch API).

.then() :

What I’m doing here is calling the pokeapi endpoint, extracting the JSON body content from the response with .json(), and then writing it to a file locally with the fs node library.

But the real magic here is .then(), which allows me to specify what happens after a response is received from a promise.

You can read it like:

• Fetch data from a REST endpoint.
• .then() once I’ve got something, extract the usable part (the JSON).
• .then() once it is usable (.json() also returns a promise), write the data onto a file.

Stringing .then() blocks one after the next is why this method of handling promises is also called promise chaining.

Next, we have an example of the same thing, but using async await:

To implement this, you just put the async keyword before your function declaration. For calls inside the function that return promises, put the await keyword before those.

This can be read like:

• Wait for the return content from the fetch() request.
• Wait for the .json() method to extract the JSON body content.
• Write the data to a file.

Using await actually stops the execution of subsequent lines of code within the async function, until the promise on that line is fulfilled. Because of this, it feels a bit more magical. It reads more like synchronous code, as if you never were actually waiting for anything.

My personal preference is to use promise chaining. I like the way it flows more, and I think it more clearly shows that you are dealing with asynchronous code. I’m also not a fan of the fact that I’ve created a lexical environment in my async await example, where by the time I’m writing to a file, I still have access to the response value. That just seems sloppy to me.

I also prefer how promise chaining handles errors. With promise chaining, all errors can be handled with one final .catch() block at the end of your chains of .then()'s.

Like so:

With async await, the main example I’ve seen is to use a try catch block:

It’s not the worst, but it’s just a little more difficult to reason about, in my opinion.

Conclusion

So what have we learned today?

• Programs are like dogs.
• A promise is like a dog waiting for their owner to come home before relieving themselves. But the dog (a program), can continue to do other dog things in the meantime.
• There’s a REST API for Pokemon (this might be the most important lesson).
• People have strong opinions.
• Promises are pretty amazing, and you should try using them either with .then(), or with async await.

This article is part of a series on digestible code concepts for folks newer to web development, who are searching for better approaches to solving problems with code.