Forem: varshini-as

How the JavaScript Event Loop Actually Works

varshini-as — Sun, 26 Jan 2025 12:07:21 +0000

Introduction

JavaScript runs on a single thread — it can only do one thing at a time — yet it manages to juggle asynchronous operations like fetching data from a server or responding to user interactions without making the page unresponsive. The secret behind this coordination is the Event Loop, which decides when and how each task gets executed.

In this article, we’ll break down the event loop step by step — using clear visuals and GIFs — so you can see what happens inside the call stack, task queue, and microtask queue. By the end, you’ll understand exactly why your async code behaves the way it does.

What is the Event Loop?

The event loop is the mechanism that enables JavaScript to handle asynchronous operations while remaining single-threaded. It ensures non-blocking execution by coordinating between the call stack, web APIs, callback queues, and microtask queues.

Now, let’s take a closer look at each part that makes this process work.

Components of the Event Loop

To understand the event loop better, let’s break it into its key components:

Call Stack - The call stack is where JavaScript keeps track of function calls. Functions are pushed onto the stack when invoked and popped off when they finish execution.
Web APIs/Node APIs - These provide the environment for asynchronous tasks like setTimeout(), fetch, and DOM events. They are managed outside the call stack.
Callback Queue (Task Queue) - When an asynchronous operation completes, its callback is queued here to await execution.
Microtask Queue - Tasks like Promise resolutions and MutationObserver callbacks are queued here. This queue is prioritized over the callback queue.
Event Loop - The event loop continuously checks if the call stack is empty and, if so, pushes the next task from the callback or microtask queue onto the stack.

How it works (Step-by-step example)

Let's consider the following code snippet to understand the event loop in action:

console.log("Start");

setTimeout(() => {
console.log("Timeout callback");
}, 0);

console.log("End");

The output will be:

Start  
End  
Timeout callback

At first glance, you might expect "Timeout callback" to appear immediately after "Start", but it doesn’t.

Here's what's happening under the hood:

The JavaScript engine starts by executing the synchronous code, line by line: The console.log("Start") function is pushed onto the call stack. It executes immediately, printing "Start" to the console. After execution, the function is popped off the stack.
Next, the engine encounters the setTimeout function: The setTimeout function is pushed onto the call stack. It registers the callback function with the Web API (provided by the browser or runtime like Node.js). After registering the callback, setTimeout is popped off the stack. The callback function is now waiting in the Web API environment with a timer set to 0 milliseconds.
The interpreter moves to the next line. The console.log("End") function is pushed onto the call stack. It executes immediately, printing "End" to the console. After execution, the function is popped off the stack.
Once all synchronous code is executed, the call stack is empty. The event loop checks if there are any pending tasks in the task queue:

The callback function from setTimeout is moved from the Web API to the task queue after the timer expires (0 milliseconds).
The event loop picks up the callback from the task queue and pushes it onto the call stack.
The callback function executes, printing Timeout callback to the console.
After execution, the function is popped off the stack.

Once the callback is executed and popped off the stack, the event loop moves on to the next task in the queue. But not all queued work is treated equally. JavaScript introduces another layer of complexity: Microtasks, primarily driven by Promises, actually jump ahead of the regular task queue. That’s what we’ll explore next.

Microtask Queues

Microtasks are prioritized over tasks (like setTimeout callbacks), which means they are executed immediately after synchronous code completes, even before tasks in the task queue.

To see this in action, consider this example:

console.log("Start");

setTimeout(() => {
  console.log("Timeout callback");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise resolved");
});

console.log("End");

Now, to see it in action:

Let's break down the execution flow into the following steps:

console.log("Start") is added to the Call Stack and executed immediately. console.log("Start") runs and logs "Start". console.log("End") runs and logs "End".
The setTimeout is encountered. Its callback (console.log("Timeout callback")) is handed off to the Web API and scheduled for execution after 0 milliseconds. Once the timer expires, the callback is moved to the task queue. The call stack is now empty.
The Promise.resolve() creates a resolved promise. Its .then() callback (console.log("Promise resolved")) is added to the microtask queue for execution after all synchronous code.
Synchronous code execution continues. console.log("End") is added to the call stack and executed immediately.
Once the synchronous code finishes, the event loop checks the microtask queue. The .then() callback is executed (console.log("Promise resolved")) and "Promise resolved" is logged to the console.
After all microtasks are executed, the event loop moves to the task queue.

This brings us to the output:

Start  
End  
Promise resolved  
Timeout callback

By prioritizing microtasks, JavaScript guarantees that promise resolutions or other immediate tasks are executed before moving on to other queued tasks, such as setTimeout callbacks.

Ready to take the wheel?

Now that you understand the event loop, let's put that knowledge into practice! Try to predict the output of the following code snippet and compare it with the actual output:

console.log("Start");

setTimeout(function() {
  console.log("setTimeout 1");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise 1");
});

setTimeout(function() {
  console.log("setTimeout 2");
}, 0);

Promise.resolve().then(() => {
  console.log("Promise 2");
});

console.log("End");

Conclusion

JavaScript is single-threaded, but it uses the event loop to handle asynchronous operations.
The call stack tracks function calls, and the event loop ensures that tasks from the callback and microtask queues are executed when the stack is empty.
Web APIs (like setTimeout, fetch) manage asynchronous tasks and move their callbacks to the task queue once they complete.
Microtasks (like promises) are given priority over regular tasks, ensuring they are executed before tasks in the callback queue.

In short, the event loop is at the core of JavaScript's ability to handle asynchronous operations in a single-threaded environment. By understanding its components — such as the call stack, web APIs, callback queue, and microtask queue — you can gain deeper insights into how JavaScript executes tasks and maintains non-blocking behavior. Whether it's handling DOM events, promises, or timers, the event loop ensures smooth and responsive web applications.

Embrace the power of JavaScript's event loop, and you’ll be well on your way to mastering asynchronous programming! Happy coding!

JavaScript Promises: The Basics You Need to Know

varshini-as — Sun, 29 Sep 2024 11:24:04 +0000

Introduction

JavaScript is single-threaded, like a one-man band, and can only handle one task at a time. So what happens when it faces multiple tasks, like fetching data from an API or waiting for a timer? Without the right tools, this can slow down your app or even cause it to freeze.

Enter Promises—JavaScript’s way of juggling asynchronous tasks without dropping the ball. Promises allow you to write more efficient, cleaner, and easier-to-understand code while avoiding the infamous “callback hell” that often makes code hard to follow.

In this guide, we’ll explore what Promises are, how they work, and why they are key to handling asynchronous tasks in JavaScript.

What is a Promise?

Think of it like ordering a meal at a restaurant. You place your order and don’t just stand by the kitchen waiting for it. You sit back, chat with your friends, or enjoy the ambiance while your food is being prepared in the background. The restaurant promises to bring your meal when it’s ready. And you trust that, eventually, one of two things will happen: either your meal arrives (fulfilled) or the kitchen tells you they can't make it (rejected).

In JavaScript, Promises work in a similar way. When you ask JavaScript to do something that takes time—like fetching data from a server—it returns a Promise. This Promise doesn’t immediately give you the result. Instead, it tells you, “I’ll get back to you when the work is done.” During that time, the rest of your code continues to run. Once the task is complete, the Promise is either:

Fulfilled (the task succeeded), or
Rejected (the task failed), and you can handle the outcome accordingly.

How Promises work in JavaScript

A Promise is a placeholder for a value you might not have yet. It can be in one of three states:

Pending: The task is in progress, and the outcome isn’t known yet.
Fulfilled: The task was successful, and the result is available.
Rejected: The task failed, and there's an error to handle.

1. Creating a Promise

To create a Promise, you use the Promise constructor, which takes a function (known as the executor) that has two parameters: resolve and reject. The resolve function is called when the Promise is fulfilled, while the reject function is called when it is rejected.

const myPromise = new Promise((resolve, reject) => {
  // Simulating an asynchronous task (e.g., fetching data)
  const success = true; // Simulate success or failure

  if (success) {
    resolve("Operation completed successfully!"); // Fulfill the promise
  } else {
    reject("Operation failed."); // Reject the promise
  }
});

2. Resolving and Rejecting Promises

Once a Promise is created, you can decide its outcome by calling either resolve or reject:

resolve(value): Call this function when the asynchronous operation completes successfully. It passes a value to the handlers that are waiting for the Promise to be fulfilled.
reject(error): Call this function when the operation fails. It passes an error message to the handlers that are waiting for the Promise to be rejected.

3. Consuming Promises

Once you've created a Promise, the next step is to consume it. JavaScript provides several methods for handling the outcomes of Promises: .then(), .catch(), and .finally(). Each one helps you manage what happens when a Promise is either fulfilled (successful) or rejected (failed).

Handling Resolved Promises with .then(): When a Promise succeeds, we use .then() to tell JavaScript what to do with the result. It takes two optional arguments: one for when things go right, and another for when things go wrong (though using .catch() is more common for handling errors).

const fetchData = () => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("Data fetched successfully!");
    }, 1000);
  });
};

fetchData()
  .then(result => {
    console.log(result); // Logs: Data fetched successfully!
  });

Handling Rejections with .catch(): If something goes wrong in the Promise, .catch() helps you handle that error cleanly. Think of it as your safety net—it catches any rejections and gives you a chance to handle the error.

const fetchWithError = () => {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      reject("Error fetching data."); // Simulating an error
    }, 1000);
  });
};

fetchWithError()
  .then(result => {
    console.log(result);
  })
  .catch(error => {
    console.error(error); // Logs: Error fetching data.
  });

Running Code After Everything Settles with .finally(): The .finally() method is a great way to clean up or run final tasks after the Promise is finished—whether it was successful or not. It’s perfect for actions that should always happen, like closing a loading spinner or clearing resources.

fetchData()
  .then(result => {
    console.log(result); // Logs: Data fetched successfully!
  })
  .catch(error => {
    console.error(error); // Handle error
  })
  .finally(() => {
    console.log("Promise has settled."); // Logs after either success or failure
  });

To be concise:

then(): Use this method to handle the resolved value of a Promise.
catch(): Use this method to handle errors when a Promise is rejected.
finally(): This method runs code after the Promise settles, regardless of the outcome, allowing for cleanup or final actions.

4. Promise Chaining

One of the coolest things about Promises is that you can chain them together. This lets you run multiple asynchronous tasks in sequence—where each task waits for the one before it to finish. This is super handy when tasks depend on each other, like fetching user data first and then grabbing their related posts.

Let's take a look at the following example:

const fetchUserData = () => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({ userId: 1, username: "JohnDoe" });
    }, 1000);
  });
};

const fetchPosts = (userId) => {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve(["Post 1", "Post 2", "Post 3"]); // Simulated posts
    }, 1000);
  });
};

// Chaining Promises
fetchUserData()
  .then(user => {
    console.log("User fetched:", user);
    return fetchPosts(user.userId); // Pass userId to the next promise
  })
  .then(posts => {
    console.log("Posts fetched:", posts);
  })
  .catch(error => {
    console.error("Error:", error);
  });

In this example, the fetchUserData() function first returns a Promise that resolves with user info. Once that Promise is fulfilled, the .then() passes the user data to fetchPosts(), which fetches their posts. By chaining the Promises together, you’re making sure that posts are only fetched after the user data is available.

If something goes wrong at any point, the .catch() at the end will handle any errors. This makes it much easier to manage errors without having to write a bunch of nested code.

Conclusion

In conclusion, Promises are a crucial part of modern JavaScript, enabling developers to handle asynchronous operations in a more structured and efficient way. By using Promises, you can:

Simplify the management of asynchronous tasks and avoid callback hell.
Chain multiple asynchronous operations to maintain a clear flow of execution.
Effectively handle errors with a unified approach.

As you implement Promises in your own projects, you'll find that they not only improve code readability but also enhance the overall user experience by keeping your applications responsive. I hope that this journey through JavaScript's foundational concepts has provided valuable insights for developers. Happy coding!

Deep Dive into JavaScript: Lexical Scope, Closures and "this" keyword

varshini-as — Sun, 24 Mar 2024 16:15:12 +0000

Introduction

JavaScript, widely known as the programming language of the Web, proves to be a fundamental tool for creating interactive user interfaces and powering backend functionalities. As we delve deeper into the world of JavaScript, we come across intriguing concepts like lexical scope, closures, and the frequently misunderstood this keyword. In this article, I aim to shed light on these three concepts and demonstrate how lexical scoping intertwines with closures and the dynamic resolution of the this keyword.

Understanding Lexical Scope

When we talk about lexical scope in JavaScript, we're referring to how variables and functions become accessible based on their placement within the code's physical structure, such as nested blocks or functions. This concept is fundamental, since JavaScript uses lexical (static) scoping to resolve variable names at write time.

Lexical scope:

Cares about where variables and functions are defined.
Considers nesting of blocks or functions.
Determines scope based on where variables and functions are defined within this nested structure, not just where the code physically exists in the file.

This leads to the following lexical scoping rules:

Inner functions or blocks can access variables declared in their outer function or block.
Inner scopes can reassign variables declared with let or var from outer scopes within the same scope or inner scopes.
Inner scopes cannot directly modify const variables declared in outer scopes by reassigning the entire variable reference. However, they can modify properties of objects and arrays declared with const if those properties are mutable.
When a variable is referenced, JavaScript looks for variables or functions starting from the current scope and then progressively through outer scopes until reaching the global scope, allowing for a hierarchical resolution of identifiers.

Let's consider the following example:

function greet() {
  const message = 'Hello';

  function sayHello(name) {
    console.log(`${message}, ${name}!`);
  }

  sayHello('John'); // output: Hello John!
}

greet();

In this example, message is defined within the greet function's scope, allowing the sayHello function to access it due to lexical scope rules. When greet is called, it invokes sayHello with the argument 'John', resulting in the output "Hello, John!".

Now, how about the next one?

function greet() {
  let greeting = 'Hello'; 

  const person = { name: 'Alice' }; 

  function updateGreeting(newGreeting) {
    greeting = newGreeting; 
    console.log(greeting); // Output: Updated greeting
  }

  function updateName(newName) {
    person.name = newName; // Modifying a property of an object declared with const
    console.log(person.name); // Output: Bob
  }

function updatePerson(newName) {
    // Attempting to reassign the entire object reference for a const variable (will result in an error)
    person = { name: newName }; // Error: Assignment to constant variable
  }

  updateGreeting('Updated greeting');
  updateName('Bob');
  updatePerson('Jane');
}

greet();

Let's break down the behavior of the three inner functions:

updateGreeting: This function takes a new greeting as an argument and updates the greeting variable declared with let. Since let variables are mutable, we can reassign their values within the same scope or inner scopes. Therefore, we get the output as the updated value "Updated greeting".
updateName: This function takes a new name as an argument and modifies the name property of the person object declared with const. The const keyword allows the modification of properties if the properties themselves are mutable. Hence, this function successfully updates and logs the new name "Bob".
updatePerson: This function attempts to reassign the entire object reference of the person object to a new object with a different name. However, since person is declared with const, it cannot have its reference reassigned after initialization. This attempt to reassign the object reference leads to an error (TypeError: Assignment to constant variable).

Now that we have a solid understanding of lexical scoping rules, let's delve into one of the most powerful concepts that stems from it: closures.

Exploring Closures

Closures in JavaScript are like a dynamic duo formed by a function and the environment it's created in. They work hand in hand with lexical scoping, allowing a function to retain accessibility to its surrounding variables even after the outer function has finished executing.

Take a look at the following snippet:

function outerFunction() {
  const message = 'Hello';

  function innerFunction() {
    console.log(message); // Accessing message from outerFunction
  }

  return innerFunction;
}

const myClosure = outerFunction();
myClosure(); // Output: Hello

In this example, innerFunction forms a closure with the message variable defined in outerFunction. Even after outerFunction completes its execution, myClosure retains access to message due to the closure mechanism, leading to the output "Hello".

It's important to note that closure formation occurs during the definition of the inner function, and not during runtime.

Now that we've explored how closures work within the context of lexical scope, let's shift our focus to another crucial aspect: the resolution of the this keyword.

Decoding `this` Keyword

In JavaScript, the this keyword is a special identifier that refers to the current execution context within which a function is invoked. It plays a crucial role in determining the context for accessing properties and methods.

The resolution of this varies depending on the type of function being used, particularly between regular functions and arrow functions.

Consider the following example:

const obj = {
  name: 'Alice',
  greet: function() {
    return function() {
      return this.name;
    };
  },
  arrowGreet: function() {
    return () => this.name;
  }
};

const regularGreet = obj.greet(); // Returns a regular function
const arrowGreet = obj.arrowGreet(); // Returns an arrow function

console.log(regularGreet()); // Output: undefined
console.log(arrowGreet()); // Output: Alice

The greet method returns a regular function that tries to access this.name, but because it's a regular function, this inside it refers to the global scope (or undefined in strict mode), resulting in the output being undefined.

On the other hand, the arrowGreet method returns an arrow function. Arrow functions do not have their own this context; instead, they inherit this from the surrounding lexical scope, which in this case is the obj object. Therefore, this.name inside the arrow function correctly refers to the name property of the obj object, resulting in the output being "Alice".

Hence, we can observe that:

Arrow functions maintain the lexical scope of this.
Regular functions have their own this context that depends on how they are invoked.

Conclusion:

In this journey through JavaScript's foundational concepts, we've explored the workings of lexical scope, closures, and the dynamic resolution of the this keyword.

Lexical scope, with its emphasis on variable and function accessibility based on code structure, provides a structured approach to managing scope and defining function behavior.

Closures, as dynamic pairs between functions and their environments, enable functions to retain access to variables even after their outer function execution completes, adding a layer of flexibility and persistence to our code.

The resolution of the this keyword clarifies the context within which functions operate.

By mastering these concepts, JavaScript developers can gain a deeper understanding of the language's inner workings, enabling them to write more efficient and robust code. I hope that this journey through JavaScript's foundational concepts has provided valuable insights for developers. Happy coding!

Forem: varshini-as

How the JavaScript Event Loop Actually Works

Introduction

What is the Event Loop?

Components of the Event Loop

How it works (Step-by-step example)

Microtask Queues

Ready to take the wheel?

Conclusion

JavaScript Promises: The Basics You Need to Know

Introduction

What is a Promise?

How Promises work in JavaScript

1. Creating a Promise

2. Resolving and Rejecting Promises

3. Consuming Promises

4. Promise Chaining

Conclusion

Deep Dive into JavaScript: Lexical Scope, Closures and "this" keyword

Introduction

Understanding Lexical Scope

Exploring Closures

Decoding this Keyword

Conclusion:

Decoding `this` Keyword