How to chain multiple promises in JavaScript

When dealing with asynchronous operations, promises give us the ability to write clearer, more manageable code than tangled callbacks ever could. Promise chaining is the core pattern that transforms asynchronous flow from a nested mess into a linear, readable series of steps.

At its essence, promise chaining allows you to take an asynchronous operation, perform an action when it completes, and then pass the result forward to the next step, all without deeply nested structures. This means each step in the chain returns a promise, and the next then waits for that promise to fulfill before running.

Consider a scenario where you need to fetch user data, then fetch that user’s posts, and finally display those posts. Here’s how a chained promise might look:

fetchUser(userId)
  .then(user => fetchPosts(user.id))
  .then(posts => displayPosts(posts))
  .catch(error => console.error("Something went wrong", error));

Notice how each function returns a promise. The magic here is that the output of one then feeds straight into the next. You don’t have to worry about deeply nested callbacks or manually tracking states.

Another critical detail is returning values (or promises) from within then. This controls what flows down the chain. The promise system waits for each returned promise to resolve before moving on. If you return a regular value, it wraps it in a resolved promise automatically.

Here’s a more explicit example where you transform data across multiple steps:

getData()
  .then(data => {
    const processed = processData(data);
    return processed;
  })
  .then(processed => saveToDatabase(processed))
  .then(result => console.log("Save successful:", result))
  .catch(err => console.error("Error during flow:", err));

Each step does one thing and returns something the next step can work with. This linear structure enhances clarity and control over the overall asynchronous sequence, making it much easier to reason about.

Beware, though: never forget to return promises inside then blocks if subsequent steps depend on them. Omitting those returns breaks the chain, resulting in parallel executions rather than sequential ones.

Also, promise chaining is just as effective when you need to incorporate synchronous steps amidst asynchronous ones. Returning a raw value in a then automatically wraps it in a resolved promise, so chaining continues seamlessly.

As an example:

getUserInput()
  .then(input => sanitize(input))        // synchronous step
  .then(cleanInput => validate(cleanInput))  // synchronous validation
  .then(validInput => sendRequest(validInput))  // async request
  .then(response => handleResponse(response))
  .catch(error => console.error(error));

The synchronous steps exist neatly within a promise chain, preserving a clean flow from start to finish. This means you can treat asynchronous sequences almost like synchronous code—one action after another—without chaos.

What can still trip you up is when a function inside a then neither returns a promise nor a value explicitly, causing subsequent then handlers to receive undefined and possibly break the chain logic. That’s why it’s vital to always return something meaningful or at least undefined explicitly.

Managing errors effectively in chained promises

Errors in promise chains behave differently than in synchronous code. When a promise in the chain rejects or when a synchronous error is thrown inside a then, the control jumps immediately to the nearest catch, skipping all following then callbacks.

This characteristic is important because it centralizes error handling, avoiding scattered try-catch blocks and making it easier to maintain.

Consider a chain where one step might fail:

fetchData()
  .then(data => processData(data))
  .then(result => saveResult(result))
  .catch(err => {
    console.error("Failed during processing or saving:", err);
  });

If either processData or saveResult throws or returns a rejected promise, the catch handler runs. This unified error funnel simplifies debugging and recovery.

One subtlety is how errors in then callbacks themselves trigger rejection. If you write:

somePromise
  .then(() => {
    throw new Error("Oops");
  })
  .catch(err => console.error("Caught:", err.message));

The thrown error is automatically caught as a rejection and passed to catch. This is a far tighter integration than you’d see in callback style handling.

Sometimes, you want to catch errors for specific steps but continue the chain afterward. You can do this by placing a catch inside the chain, like so:

stepOne()
  .catch(err => {
    console.warn("Recovering from error in step one:", err);
    return defaultValue;
  })
  .then(value => stepTwo(value))
  .catch(err => console.error("Error in step two or later:", err));

Here, if stepOne fails, the catch recovers by returning a fallback value, allowing stepTwo to run. Errors downstream are still caught by the later catch.

Another common pattern is to rethrow errors after logging or cleanup, to let outer handlers deal with them:

doSomething()
  .catch(err => {
    logError(err);
    throw err; // rethrow so higher-level handlers see it
  })
  .then(() => {
    // This won't run if doSomething failed and the error was rethrown
  });

Failing to rethrow a handled error effectively signals success, which might mask problems. The difference between catch-and-handle versus catch-and-rethrow is subtle but important.

To avoid catching unrelated errors prematurely, place catch handlers only where you can meaningfully handle or recover from errors. Global catch handlers at the end of the chain serve as the last line of defense, which is best practice.

It’s also worth noting that finally handlers are available to run cleanup logic irrespective of success or failure, without affecting the promise chain resolution:

asyncTask()
  .then(result => useResult(result))
  .catch(error => handleError(error))
  .finally(() => cleanupResources());

Unlike then or catch, the finally callback neither receives data nor affects the promise’s fulfillment state, making it ideal for side-effect cleanup.

In summary, effective error management in promise chains hinges on:

– Understanding that thrown errors or rejected promises jump to the next catch.

– Using intermediate catch blocks for selective recovery.

– Rethrowing errors if you don’t want to signal resolution prematurely.

– Placing a global catch handler to avoid unhandled promise rejections.

– Using finally for guaranteed cleanup.

For instance, here is a robust pattern combining these principles:

loadConfig()
  .then(cfg => initializeApp(cfg))
  .catch(err => {
    reportError(err);
    throw err; // escalate after logging
  })
  .then(() => startServices())
  .catch(err => {
    console.error("Startup failed", err);
  })
  .finally(() => {
    console.log("Startup sequence complete (success or failure)");
  });

This style clearly separates concerns: initial errors get logged and escalated, subsequent errors get handled explicitly, and final cleanup always occurs.

Refactoring callbacks into chains for better readability

Refactoring callbacks into promise chains not only increases readability but also enhances maintainability of your asynchronous code. When you convert nested callbacks into a flat structure using promises, you eliminate the so-called “callback hell” and create a more linear flow that’s easier to follow.

Imagine you have a series of operations that depend on each other, all wrapped in callbacks. It can quickly become difficult to read and manage. Here’s a common pattern of deeply nested callbacks:

getUser(function(user) {
  getPosts(user.id, function(posts) {
    displayPosts(posts, function() {
      console.log("Posts displayed.");
    });
  });
});

That’s unwieldy. By refactoring these callbacks into promises, you can simplify the entire structure:

getUser()
  .then(user => getPosts(user.id))
  .then(posts => {
    displayPosts(posts);
    console.log("Posts displayed.");
  });

Notice how each function returns a promise that allows the next step to execute only after the previous one has completed. This eliminates the need for nested function calls and makes the code much cleaner.

One of the significant advantages of using promises is that they allow you to handle asynchronous operations in a way that resembles synchronous code. This makes it easier to reason about the flow of data through your application.

For example, if you need to perform some data processing after fetching user data and posts, you can continue chaining:

getUser()
  .then(user => getPosts(user.id))
  .then(posts => processPosts(posts))
  .then(processedPosts => displayPosts(processedPosts))
  .then(() => console.log("All done!"))
  .catch(error => console.error("An error occurred:", error));

Each promise in the chain handles its own asynchronous operation, and if any step fails, the error is caught in the final catch block. This centralizes error handling and keeps your code organized.

To further illustrate, let’s say you need to validate user input before proceeding with further operations. In a callback style, this would likely lead to more nesting. However, with promises, you can handle validation seamlessly:

getUserInput()
  .then(input => validateInput(input))
  .then(validInput => getUser(validInput))
  .then(user => getPosts(user.id))
  .then(posts => displayPosts(posts))
  .catch(error => console.error("Error:", error));

This approach makes it clear what each step does and how data flows from one function to the next. Each promise is responsible for its own part of the process, contributing to a clearer logic structure.

Moreover, if you need to perform cleanup or other final operations regardless of success or failure, you can use finally at the end of your chain:

getUser()
  .then(user => getPosts(user.id))
  .then(posts => displayPosts(posts))
  .catch(error => console.error("Error processing:", error))
  .finally(() => {
    console.log("Finished processing user posts.");
  });