Design Patterns and Architecture Behind JavaScript Promises

Introduction

JavaScript Promises are very essential in the current modern web development since they have a say in handling critical, asynchronous operations. For example, some of the processing activities, like API calls, file operations, and many others, types of activities execution will be needing elements of waiting without necessarily blocking the main thread. Every developer who wants to write efficient, manageable, and scalable code should understand the architectural underpinnings of the JavaScript promises and design patterns.

What are JavaScript Promises?

A JavaScript Promise is an object that represents the eventual completion of an asynchronous operation. In simpler terms, it sounds like a placeholder for a value to be known later, hence making running your JavaScript code asynchronously much easier and friendly.

Design Patterns Used in JavaScript Promises

JavaScript promises utilize several design patterns that help in structuring the complex flow of asynchronous operations:

State Machine:

Promises operate as state machines with three states:

• Pending: Initial state, neither fulfilled nor rejected.
• Fulfilled: The operation was successfully carried out.
• Rejected: Operation rejected.

This structure helps in controlling state transitions in a sane manner, by ensuring that a promise can settle (fulfill or reject) at most once, hence reducing the possibilities of timing and ordering errors in programming.

Code Example:

const promise = new Promise((resolve, reject) => {
    const condition = true;
    if (condition) {
        resolve("Promise is fulfilled");
    } else {
        reject("Promise is rejected");
    }
});

promise.then((result) => {
    console.log(result);
}).catch((error) => {
    console.error(error);
});

// Output: "Promise is fulfilled"

This is the sample in which Promise starts in the ‘pending’ state and then, on the basis of condition, it changes to ‘fulfilled’ (calling .resolve()) or ‘rejected’ (calling .reject()). After all, the Promise resolved or rejected; it is already in the settled state. It can’t change the state again; hence, it provides immutability and evenness of behavior throughout the application.

Observer Pattern:

This pattern is particularly vital for promises as it allows multiple observers (callbacks) to be registered. The observers are called only when the state of the promise has changed. This is similar to subscribers that are notified when a particular event they are interested in happens.

It should be noted that the.then(), .catch(), and .finally()methods are attached to the success and failure of the promise. Functions can be attached to ..then()in a chain, allowing them to “observe” the resolution of the promise and be called with the returned result.

Code Example:

const loadData = () => {
    return new Promise((resolve) => {
        setTimeout(() => resolve("Data loaded"), 2000);
    });
};

const dataPromise = loadData();

dataPromise.then(data => console.log(data));

// Output after 2 seconds: "Data loaded"

Here, loadData returns a promise. The.then()method is used to subscribe a function that will run once the data is loaded. This pattern allows multiple callbacks to be added, and they will be invoked when the promise resolves.

Command Pattern:

Callback functions used in .then()or.catch()look like commands, enabling delayed execution and flexibility in handling outcomes. This pattern decouples the event initiation from event handling, allowing for modular and reusable code structures.

Code Example:

promise
    .then(result => {
        console.log(result);
        return result.toUpperCase();
    })
    .then(modifiedResult => {
        console.log(modifiedResult);
    })
    .catch(error => {
        console.error(error);
    });

In this chained example, each.then()and.catch()callback acts as an individual command. Each command handles the outcome of the promise or the result of the previous command in the chain, showcasing the separation of concerns and encapsulation of actions.

Proxy Pattern:

That is evident in the case where promises are used to represent data that may be unavailable at the time but probably available sometime in the future. This way, it allows a developer to write codes that can operate using these future values as if they were available already.

Code Example:

const fetchData = () => new Promise(resolve => {
    setTimeout(() => resolve("Fetched data"), 1000);
});

const dataPromise = fetchData();

dataPromise.then(console.log);

// Logs "Fetched data" after 1 second

The promise returned by fetchData()acts as a stand-in for “Fetched data” before it is actually available. The rest of the code can be written as if “Fetched data” is already there, simplifying asynchronous programming.

Decorator Pattern:

Each call to.then()or.catch()in the chaining doesn’t handle the promise resolution but probably changes the value being passed along the chain or takes care of specific errors, hence changing the behavior or altering the outcome of the promise, making the chaining through.then()to be done with the Decorator pattern.

Code Example:

const calculate = (num) => new Promise(resolve => resolve(num));
calculate(10)
    .then(result => {
        return result + 10;
        // Adding 10
    })
    .then(newResult => {
        console.log(newResult);
        // Output: 20
        
        return newResult * 2;
        // Multiplying by 2
    })
    .then(finalResult => {
        console.log(finalResult);
        // Output: 40
    });

Each.then()method enhances the value passed along the promise chain by adding new behavior (e.g., adding 10, then multiplying by 2). This demonstrates how behavior can be layered onto a promise, modifying its outcome progressively.

Builder Pattern:

This pattern allows us to build up a complex sequence of asynchronous operations step by step. It provides fluent API abilities to further add behaviors (like adding another.then()or .catch()call) in a nice, readable way.

Code Example:

const startProcess = () => new Promise(resolve => resolve("Start"));

startProcess()
    .then(step1 => step1 + " -> Step 1")
    .then(step2 => step2 + " -> Step 2")
    .then(result => console.log(result));

// Output: "Start -> Step 1 -> Step 2"

Here, each.then()method builds on the previous step, constructing a sequence of operations. This pattern is useful for managing complex asynchronous workflows in a readable and maintainable manner.

Architectural Overview

Promises are part of the ECMAScript specification, ensuring consistent behavior across different JavaScript environments. This specification defines an execution model, methods, and the behavior of a promise — all combining to render a reliable and predictable form for the structure of working with asynchronous code.

Its architecture is designed to fit naturally into the JavaScript event loop, wherein promise callbacks are treated as micro-tasks. This architecture makes sure all promises are resolved before processing other macrotasks in JavaScript; this will ensure the web application is responsive and performing well.

Promises integrate with this model tightly:

• Microtask Queue: Promise callbacks (like those from .then(), .catch(), and .finally()) are treated as microtasks in the JavaScript environment. This means they are executed before any other asynchronous task (such as those managed by setTimeout or setInterval, which are macrotasks). This priority makes sure that the promise's resolution gets to happen right after the currently executed script stack is finished, but before the JavaScript engine proceeds with executing other tasks from different task queues.
• Non-Blocking: The promise-based code runs through the event loop and does not block the main thread. This frees UI and other scripts running without interruption. When a promise is resolved or rejected, queue the respective handlers to be executed in the next cycle of the event loop, hence it does not block the subsequent operations and the application stays responsive.

Understanding these patterns and the architecture of promises enhances a developer’s ability to write effective asynchronous JavaScript code. Here are some practical benefits:

• Error Handling: Promises provide a structured way to catch and handle errors through chaining, which can significantly reduce the chances of unhandled errors and improve the reliability of web applications.
• Synchronization: Handling multiple asynchronous operations becomes more manageable with Promise.all(), Promise.race(), Promise.allSettled(), and Promise.any(), which are built on the promise architecture to synchronize and manage multiple promises.
• Testability: The modular nature of promise-based code improves its testability. Each part of the promise chain can be tested separately, and mock promises can be used to simulate different states of asynchronous operations.

Conclusion

Understanding the patterns and principles behind JavaScript promises is more than an academic exercise; it’s a practical necessity for developing responsive and efficient applications. By leveraging these patterns, developers can write cleaner, more maintainable code that effectively handles asynchronous operations, a staple in today’s web development landscape.

In essence, promises are not just a feature of JavaScript, but a reflection of thoughtful design and architecture aimed at solving one of the most challenging problems in programming: managing asynchronicity in a synchronous programming environment.

Thank you for spending time on reading the article. I genuinely hope you enjoyed it, and don’t forget to read previous articles.

If you have any questions or comments, please don’t hesitate to let me know! I’m always here to help and would love to hear your thoughts. 😊

Data Injection: Strategies for Seamless Client-Server Integration

Journey to the Center of Our AWS Migration Battle: Part I

Journey to the Center of Our AWS Migration Battle: Part II