Refactoring JavaScript

Chapter 10. Asynchronous Refactoring

In this chapter, we’ll discuss asynchronous (aka “async”) programming in JavaScript, by covering the following topics:

• Why async?
• Fixing the “pyramid of doom”
• Testing async code
• Promises

Why Async?

Before we get into how to make asynchronous JavaScript better through refactoring, it’s worth discussing why we need it. Why shouldn’t we just use a “simpler” synchronous style and not worry about async at all?

As a practical concern, we want our programs to be performant. Despite our focus in this book being interfaces rather than performance, there is another issue, even if we thought it was okay to hold up our whole program for a web request or data processing task that could take seconds, minutes, or even longer: sometimes async is the only option for a given module or library.

Async has become the norm for many APIs. For example, one coming from a mostly synchronous paradigm (language or style) might expect node’s http module to behave like this:

const http = require('http');
const response = http.get('http://refactoringjs.com');
console.log(response.body);

But this will print undefined. The reason is that our response constant is actually named a bit optimistically. The return value of http.get is a ClientRequest object, not a response at all. It describes the request, but not the result.

There are good reasons to use asynchronous remote HTTP calls. If our remote call were synchronous, it would necessarily “stop the world” (STW) and keep ...