How to Improve Your Asynchronous JavaScript Code With Async and Await

Indrek Lasn
Jan 6 · 6 min read
Photo by Max Nelson on Unsplash

If you’ve had the chance to observe modern JavaScript code, there are high chances that you’ve seen the async and await syntax somewhere.

Async/await is arguably one of the best-received new additions to the language. Async/await makes the asynchronous code appear and behave like synchronous code. Async/await are promise-based.

Before we jump into async/await, we must understand what promises are and the role they play.

Promises

A Promise is an object representing the eventual completion or failure of an asynchronous operation.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises

Why do we need the asynchronous code, anyway?

JavaScript is a single-threaded language — which means JavaScript can only do one thing at once. Imagine calling our API synchronously and blocking the entire thread for the API call duration — our users would have to wait 30 seconds or as long it takes for the network request to resolve — a big no-no!

In case you’re interested to learn more — here’s a more in-depth explanation about asynchronous programming with JavaScript.

The way we used to handle asynchronous JavaScript code was via callbacks. Chances are high that you’ve come across callbacks.

What are callbacks?

A callback function, also known as a higher-order function, is a function that is passed to another function. Functions are first class citizens in JavaScript — this means they can be passed as arguments to functions.

You might have seen jQuery specific code like this.

The following code attaches an event listener on our button and calls the alert once it’s triggered.

Where is the callback? Can you tell?

You probably can — it’s the anonymous function inside the click function parentheses.

https://javascriptissexy.com/understand-javascript-callback-functions-and-use-them/

Callbacks in a nutshell: we trigger a function, do some stuff, and then call another function.

Callbacks are not all bad; they worked — they still do. But, what happens if we have a callback inside a callback, inside a callback — you get the point. It gets really messy and unmaintainable really quick.

The problem described above is named “callback hell.”

http://callbackhell.com/

Here’s one more example to seal the case for callbacks.

We have a melon!

We check if we have a melon inside the array — if we do, we chew the melon. After chewing, we throw away the melon. We’re also handling exceptions with the err callback.

Hey — we have a banana instead!

Note: the err callback is always the first argument in the Node world — best practices!

Just to throw you off a little — I made the previous code as readable as I can. Here’s how it might look more often:

mini callback hell; technically, having anonymous arrow functions would be the remedy but still is not the perfect solution.

You can imagine, a couple more callbacks and we’re on the highway to [callback] hell — pun intended!

Promises to the Rescue!

Promises are a clean way to write asynchronous code. The promise has a single argument, which is a callback.

The callback has two arguments, the reject and resolve conditions.

And if we use the arrow function to shorten the code:

Inside the promise block, we can decide when to resolve and when to reject the promise.

Inside the promise we check if we have a melon. If we do, let’s resolve the function with the value we pass inside resolve — we can pass literally any value to the resolve.

Promises are immediately invoked/resolved, thus why we see the console.log without calling the promise.

Promises are called and chained with the then and catch methods. Think of it like this: the promise has resolved with a value — what do we do with it?

This is where the then and catch syntax comes in. They are both callbacks which accept one argument, which is the return value passed inside the promise.

Here’s how we could handle a promise rejection:

Handling a promise rejection with catch()

Right, now our promise is not very dynamic — why?

Well, because we have an if statement that isn’t dynamic. Promises are extremely powerful when wrapped inside a function. We call them higher order functions.

Wrapping our promise inside a function

Do you notice the small change? We wrapped our promise inside a function which takes one argument in this case. This gives our promises huge flexibility. We can pass any condition to our promise and based on that condition, it will get either rejected or resolved.

Here’s the fully working promise which gets resolved.

Resolved promise

And the rejected promise.

Rejected promise

Starts to look familiar? You might have seen Axios API calls like the one below.

Axios API call example (promise based)

Or the fetch API call;

Fetch API call example (promise based)

What do they have in common?

Well, for starters they’re both a promise. They’re fundamentally using promises under the “hood”. Just like we wrapped our promise inside a function, so do both of these examples.

Secondly, they’re both asynchronous code. Promises are naturally asynchronous.

Here’s how an asynchronous API call looks like:

It’s safe to say promises are much better than callbacks. Promises have their own flaws although — promises can get out of hand quite quickly.

What if there’s a better way, an even cleaner way. Async/await to the rescue!

We mark the function as async — inside the function we mark the asynchronous code with await . JavaScript will resolve the promise and then move on to the next line. In a nutshell, we change the asynchronous code to read like synchronous code while still running asynchronously.

Notice how we don’t call the promise constructor anymore and how there are much less then() and catch() methods.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

What About Error Handling?

Our current async/await doesn’t handle exceptions. This can lead to catastrophic bugs which might crash your app.

Try…catch to the rescue!

Wrapping our async function inside try catch block

The try catch block attempts to execute the code and if it runs into any exceptions/problems, it passes the error object to the catch block and executes the code inside the catch block.

Here’s how our async/await fetch would look with error handling.

This is just one of many examples, there are many ways to leverage async/await. If you’re curious — here’s a pretty good example StackOverflow answer exploring the alternatives.

If you really want to know how to manage promises and how asynchronous JavaScript code works, I recommend reading through the “JavaScript with Promises: Managing Asynchronous Code” book.

Thanks for reading and I hope you found this useful! ❤

Better Programming

Advice for programmers.

Indrek Lasn

Written by

Engineer, founder. Let’s change the world together for the better. Follow me on Twitter @ https://twitter.com/lasnindrek

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade