In JavaScript, closures are a powerful feature that allows functions to retain access to their lexical scope, even when executed outside of that scope. Understanding closures can significantly enhance your coding skills, especially in modern frameworks like React, where closures are frequently used to manage state and side effects.

This article dives into the concept of closures, exploring their fundamental principles, practical applications in JavaScript, and their implementation in React custom hooks.

By the end of this article, you’ll have a solid understanding of how closures work and how they can be leveraged to write more efficient and maintainable code.

What is closure?

A closure is a JavaScript feature which allows us to access variables from an enclosing scope to the outer scope. We are not explicitly creating the closures, but JavaScript engine creates a closure at the time a function is declared. The closure is possible because of lexical scope and first class functions.

Probably the above description wouldn’t make much sense now but at the end of this article, when you come back to this description, it will totally make sense.

Before we dive into closures, let’s revisit the last example from the scope chain article.

Scope chain revisit

From the scope chain article, let’s see the last example again.

function myFuncOne() {
  var msg = 'Kia ora';

  function myFuncTwo() {
    console.log(msg);
  }

  myFuncTwo();
}

var msg = 'Anyong';
myFuncOne();

Output:

Kia ora

The function, myFuncTwo(), lexically sits inside the myFuncOne() so it makes the outer reference of the myFuncTwo() to myFuncOne() and it found the var msg = 'Kia ora' so it logs Kia ora.

Now let’s update the code by returning myFuncTwo function (it is possible because of the first class function) instead of calling it inside myFuncOne (line 8) and see how the closure works.

Closures and execution context

Let’s see the code below. We are now returning the myFuncTwo by making it as an anonymous function.

function myFuncOne() {
  var msg = 'Kia ora';

  return function() {
    console.log(msg);
  }
}

Now let’s call the myFuncOne function.

myFuncOne()();

and it returns:

Kia ora

So let’s think about it again.

When we call myFuncOne(), it will return the anonymous function (line 4):

and to call the returned function again, we just need to add another parentheses, myFuncOne()().

Now let’s invoke the function another way. This time we will assign the first function call to a variable and then call the returned function.

const funcOneCall = myFuncOne();
funcOneCall();

With this, there is an interesting thing happening. When we call myFuncOne(), the msg variable was created and it completed the execution, meaning it’s popped off the execution stack, however, when we invoke funcOneCall(), it still can access the msg value. How can this happen? It’s because of closure.

The closure is created when the function is declared (not called) and it keeps access to the variables of the outer function.

Let’s take a look at this again in the execution context.

When the JavaScript file is first loaded in the browser, JS engine first creates the Global Execution Context.

When we invoke const funcOneCall = myFuncOne();, new execution context is created and the msg variable will sit in the variable environment of the execution context.

And when it returns the anonymous function (line 4 in the coding example above), the myFuncOne() execution context pops off the stack and it will look something like this:

So even if the execution context is gone, the msg variable is still in the memory heap. Let’s keep going and see what happens next.

Now we are in the Global Execution Context again and when we invoke funcOneCall(), it will create new execution context:

When it hits the console.log(msg) (line 5), JS engine sees msg. As it cannot find the msg variable inside the function itself, it goes up the scope chain and try to find the variable in the outer function where the function was created.

In many other programming languages, the heap would be garbage collected when the execution context is popped off the stack but in JavaScript, it creates a closure and JS engine makes sure it can still go down the scope chain.

So even though the myFuncOne execution context is popped off the stack, funcOneCall execution context still has a reference to the variable of the outer function. This is called closure.

Let’s now revisit the definition of closure we wrote at the beginning of this article.

A closure is a JavaScript feature which allows us to access variables from an enclosing scope to the outer scope. We are not explicitly creating the closures, but JS engine creates a closure at the time a function is declared. The closure is possible because of lexical scope and first class functions.

Does it make sense now?

Let’s see the formal definition from MDN too.

A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function. In JavaScript, closures are created every time a function is created, at function creation time.

I hope it makes sense too 😀

Now we understand what the closure is, let’s see if the above coding example really creates the closer in Chrome DevTool.

Closures in DevTools

Let’s add a debugger right before the console.log and run it in Chrome DevTools.

function myFuncOne() {
  var msg = 'Kia ora';

  return function() {
    debugger;
    console.log(msg);
  }
}

The debugger gets paused and you will see the closure having the msg variable with the Kia ora value in Chrome DevTools.

Alright, now let’s take a look at a couple more coding examples and see how it makes use of the closure.

setTimeout example

This question appears in the technical interview quite often so it would be a great opportunity to make sure we understand how the closure works with setTimeout.

Let’s see the coding example first.

functione printIndex(arr) {
  for (var i = 0; i < arr.length; i++) {
    setTimeout(function() {
      console.log(i);
    }, 1000);
  }
}

printIndex([1, 2, 3]);

What do you think this function will output? Which one is correct from the below list?

0, 1, 2 in every one second delay
0, 1, 2 all together after 1 second
2, 2, 2 in every one second delay
2, 2, 2 all together after 1 second
3, 3, 3 in every one second delay
3, 3, 3 all together after 1 second

The answer is… 🥁

It will be 3, 3, 3 all together at once after 1 second. Was it what you expected?

Let’s dive into what is going on.

First, why does the output appear all at once after one second, instead of being displayed at one-second intervals as we might expect?

Summary

That’s because setTimeout() is an asynchronous Web API which enters into the event loop, then not much things to do in the loop in our code, so the for...loop finishes quickly in under a millisecond. When the loop has finished, each of the 3 tasks from the setTimeout() function (line 4) goes into the synchronous task queue scheduled to be run one second later. And when the call stack is empty, the execution context for each tasks is created and they are passed into the call stack from the task queue. So each task in the call stack now has the same 1 second delay and that’s why they run consecutively at once rather than one second intervals.

In Detail

Let's visualise it with charts to better understand how it all works.

When the JS engine runs the printIndex function, it follows a specific sequence of operations involving the call stack, the Web APIs, the task queue, and the event loop. Let’s begin with the initial JavaScript runtime environment chart.

When printIndex([1, 2, 3]) is called, it's pushed onto the call stack.

And the engine enters the for...loop inside printIndex(). During each iteration, the setTimeout function is called.

Each setTimeout call is handled by the browser's Web APIs, not the JS engine. The JS engine passes the callback function and the timer to the Web APIs and then continues executing the next lines of code (continuing the loop in this case).

The Web API starts a 1000 millisecond timer for each setTimeout. Meanwhile, the call stack is free to run other tasks; it doesn’t wait for the timer to finish. The for...loop completes quickly, scheduling all three setTimeout callbacks in rapid succession.

After 1000 milliseconds, the timers expire. The Web APIs then place the callback functions into the task queue.

The event loop constantly checks whether the call stack is empty. When it is, the event loop transfers the first callback from the task queue to the call stack.

Since all timers were set with the same duration and were started almost simultaneously, their callbacks enter the task queue around the same time. As the call stack becomes available, these callbacks are executed one after another, resulting in the console.log(i) statements executing in quick succession.

The rapid execution of the loop and the identical timer settings for setTimeout mean that all callbacks are queued at almost the same time. They are executed in rapid succession once the call stack is free, giving the appearance of the output occurring all at once after one second.

This is why the output appears all at once after one second. Again, to completely understand how this works in-depth, please check out the JavaScript engine flow article.

So how can we output the i in one second interval. To achieve that, we will need to provide the increased delay value to each setTimeout. So if we update the delay to 1000 * (i + 1), now the output appears in one second interval.

Secondly why not printing 2, 2, 2 but 3, 3, 3?
And also thirdly why not printing 0, 1, 2 but 3, 3, 3?

That is because var is function-scoped. Let’s add the i outside the for...loop and see what we are getting.

function printIndex(arr) {
  for (var i = 0; i < arr.length; i++) {
    setTimeout(function() {
      console.log(i);
    }, 1000);
  }

  console.log('outside for loop: ', i);
}

printIndex([1, 2, 3]);

We will get:

outside for loop: 3

Why are we getting 3? Let’s think about how the for...loop works again. The for...loop will start from 0 and increment its value by 1. At the 4th iteration, the i has already been increased so it is 3 but it doesn’t satisfy the condition, i < arr.length, so it won’t go inside the for...loop anymore.

So the for...loop is already finished and pops off from the stack and when setTimeout is run, it has a reference to the i which is now 3. This is closure as we saw earlier and even though we have three different closures from the loop, they are all referencing to the same i variable.

So how can we update it so we can print 0, 1, 2 instead of 3, 3, 3?

There are a couple of ways we can approach this.

IIFE (Immediately Invoked Function Expression)

An IIFE is a JavaScript function which runs as soon as it is defined. The code with IIFE will look like below:

function printIndex(arr) {
  for (var i = 0; i < arr.length; i++) {
    (function(j) {
      setTimeout(function() {
        console.log(j);
      }, 1000);
    })(i);
  }
}

printIndex([1, 2, 3]);

So each iteration will execute the IIFE and each execution creates its own execution context. Because of each execution we are passing with the i value, 0, 1, 2, j will receive it and be stored in each of the different execution context. When those execution contexts are all popped off, those 3 different j values will still be in the memory heap and that’s why we can still get to the different 3 j values with the closure.

Now let’s take a look at another approach which is possible since ES2015 was introduced.

Let

Let’s change var to let and see what happens.

function printIndex(arr) {
  for (let i = 0; i < arr.length; i++) {
    setTimeout(function() {
      console.log(i);
    }, 1000);
  }
}

printIndex([1, 2, 3]);

The let keyword was introduced in ES2015 and allows us to declare a block-scoped local variable. That means JS engine creates new version of i variable in each iteration as the curly brackets for the for...loop creates a scope for each i so i will be a different variable each time. As closures are created when the function in the setTimeout was declared (rather than executed), meaning the closures are created during the iteration and not when it was executed after 1 second. Hence, each execution context will access different i value for its own closure, effectively producing the same results as IIFE above.

I hope this example gives you a good understanding of how the closure works. Let's take a look at another example with Debounce.

Debounce example

Debouncing is a powerful technique in JavaScript, particularly useful in optimising performance for actions that don’t need to be performed immediately and can be delayed. It’s a common topic in technical interviews, often highlighting the practical use of closures in the debounce function.

In the previous article, I’ve thoroughly explored the concepts of debounce, providing detailed insights into its implementation. If you’re interested in a comprehensive guide on how to implement the debounce technique, I highly recommend checking out the article: Debounce in JavaScript. For the purpose of this discussion, however, we’ll focus specifically on the aspect of closures within the debounce function in this section.

Here is the complete code for the debounce function.

function debounce(callback, delay, immediate = false) {
  let timerId;

  const debounced = function (...args) {
    clearTimeout(timerId);

    const context = this;

    if (!timerId) {
      callback.apply(context, args);
    }

    timerId = setTimeout(() => {
      if (!immediate) {
        callback.apply(context, args);
      }

      timerId = null;
    }, delay);
  };

  function cancel() {
    clearTimeout(timerId);
    timerId = null;
  }

  debounced.cancel = cancel;

  return debounced;
}

As we learnt so far, closures allow a function to access variables from its lexical scope, even after the outer function has returned (poped off). This is key in understanding how denounced and cancel functions interact with timerId.

In the debounce function, timerId is declared at the top level of the function scope. This variable is intended to store a reference to the timer set by setTimeout.

Both the debounced and cancel functions are defined within the debounce function. Due to the nature of closures, these inner functions maintain access to the timerId variable, even after the execution context of the debounce function is popped off the call stack.

What makes this possible is the closure formed when debounce is initially called. The timerId variable exists in the lexical environment of the debounce function, and this environment is closed over by denounced and cancel. This means that even when debounce has finished executing, the timerId remains accessible to debounced and cancel, preserving its state across multiple executions and allowing these functions to interact with the same timer reference consistently.

Let’s take a look at how we are using the debounce function.

const handleClick = () => {
  console.log("handleClick triggered");
};

const debouncedClick = debounce(handleClick, 1000);

The key here is that each invocation of debouncedClick accesses the same timerId variable. This is possible because debounced (now debouncedClick) is a closure, maintaining a link to the timerId from the debounce function’s scope.

Without this closure, debouncedClick would not have access to timerId, making it impossible to clear or reset the timer on subsequent calls.

In essence, the closure created in the debounce function ensures that debounced and cancel have persistent and shared access to the timerId variable. This access is vital for the debounce functionality, allowing these functions to manage and reset the delay, ensuring that the callback function is executed at the appropriate time.

Up to this point, we’ve explored the concept of closure and examined how it’s applied in two frequently asked interview questions. Now, we’ll dive deeper into more advanced concepts of closure by examining two of its other essential attributes: memory efficiency and encapsulation. First, let’s focus on understanding how closure contributes to memory efficiency.

Memory Efficiency

Let’s take a look at the code below.

This function, myArray, is designed to create an array of 10,000 elements, where each element’s value corresponds to its index. It then returns the value at a specified index.

function myArray(index) {
  const newArray = Array.from({ length: 10000 }, (_, idx) => idx);

  return newArray[index];
}

myArray(100);
myArray(200);
myArray(300);

Now we are invoking myArray three times. Could you identify the potential problems this code may cause and suggest how we might enhance its efficiency?

Let’s add a console.log.

function myArray(index) {
  const newArray = Array.from({ length: 10000 }, (_, idx) => idx);

  console.log(‘New array created’, newArray);

  return newArray[index];
}

myArray(100);
myArray(200);
myArray(300);

and the output will be:

Each invocation of the myArray function results in the creation of the same large array. Particularly given its size, if this function is called from various places within the application, it leads to redundant creation of the identical array, incrementally consuming memory with each call.

To avoid this issue, we can leverage closures. The solution aligns with what we explored in the very first example of this article. Let’s revisit that.

const funcOneCall = myFuncOne();
funcOneCall();

So we learnt:

When we call myFuncOne(), msg variable was created and it completed the execution, meaning it’s popped off the execution stack, however, when we invoke funcOneCall(), it still can access the msg value [because of the closure]

Let’s take this into account and update our code.

function myArray() {
  const newArray = Array.from({ length: 10000 }, (_, idx) => idx);

  console.log(‘New array created’, newArray);

  return function(index) {
    return newArray[index];
  }
}

In this approach, a new array is generated only upon invoking the myArray function. This setup establishes a closure, enabling the returned inner function to access the newArray variable from the memory heap even after the myArray function has been popped off the call stack.

Let’s execute the function and see the output in the log.

const myNewArray = myArray();
myNewArray(100);
myNewArray(200);
myNewArray(300);

and here’s what the output appears as:

The array is created just once, and the inner function (myNewArray) maintains access to newArray due to closure.

This exemplifies how closures can be effectively used to optimise memory usage.

Moving forward, let's explore another vital topic, encapsulation.

Encapsulation

The closures also provide another important attribute: encapsulation. Closures allow for private variables and functions that cannot be accessed from outside the enclosing function. This is particularly useful when we want to hide certain parts of our code from the global scope or create private variables for an object.

Let’s take a look at the code example below.

function updateScore() {
  let score = 0;

  const increment = () => {
    score++;
  }

  const decrement = () => {
    score—;
  }

  return {
    increment,
    decrement,
  };
}

const score = updateScore();
score.increment(); // Output: 1
score.decrement(); // Output: 0

The code shows a simple way to manage a score using closures for encapsulation. This pattern ensures that the actual score, the score variable, is kept private and cannot be directly accessed or modified from outside the updateScore function. Instead, the score can only be modified through the increment and decrement functions that are exposed when updateScore is called.

Let’s take a closer look at the code.

When updateScore is called, it initializes a private variable score to 0. This variable is only accessible within the updateScore function’s scope. The score variable acts as a private variable. It’s not accessible from the outside, adhering to the principles of encapsulation. This prevents unauthorized parts of the code from directly changing the score, enforcing a controlled and predictable way of updating the score.

The function then defines two inner functions, increment and decrement, which update the score variable. These functions have access to score due to the closure, meaning they can access variables from their parent function’s scope even after that parent function has returned.

Then, updateScore returns an object containing references to the increment and decrement functions. This is the mechanism through which updateScore exposes the ability to modify the score while keeping the score variable itself protected and private.

This pattern of using closures for encapsulation in JavaScript is powerful for managing the state in a controlled manner. By exposing only specific parts of the code (like increment and decrement methods) and keeping others private (like the score variable), engineers can create more reliable and maintainable applications.

We learnt two important aspects from closures. Now let's see how it is applied in React.

React Custom Hooks with Closures

In the React world, closures are a fundamental part of managing state and side effects, especially when using hooks. Let's take the updateScore function from the previous example, transform it into a custom hook, and see how closures work in React.

Here is the useScore custom hook.

import { useState, useCallback } from 'react';

function useScore() {
  const [score, setScore] = useState(0);

  const increment = useCallback(() => {
    setScore((prevScore) => prevScore + 1);
  }, []);

  const decrement = useCallback(() => {
    setScore((prevScore) => prevScore - 1);
  }, []);

  return {
    score,
    increment,
    decrement,
  };
}

export default useScore;

The useState hook initialises the score state and provides a setter function (setScore) to update it (line 4). The score variable is local to the useScore hook but will be accessible by the functions defined within the hook due to closures.

The increment and decrement functions are defined inside the useScore hook. These functions form closures that capture the setScore function. This means that even when increment and decrement are called outside the useScore hook (e.g., in a component that uses the hook), they still have access to the setScore function.

🗒️ Side note: The useCallback hook is used to memoize these functions, ensuring they do not get recreated on every render. This optimization is beneficial for performance but does not impact the closure.

When the useScore hook is used in a component, the increment and decrement functions maintain their closures over the setScore function:

In conclusion, closures in the useScore hook ensures that the increment and decrement functions have persistent access to the setScore function and the score state. This enables the hook to encapsulate the state logic, providing a clean and reusable interface for managing the score in any component that uses the hook.

Next let's dive into the performance considerations especially with OOP.

Performance Considerations with OOP

The performance issue could arise from the way JavaScript functions and closures are utilised in object-oriented programming, particularly with object creation and method definitions. Let’s dive deeper into this topic.

In JavaScript, objects can be created using constructors (functions designed to create objects). A common practice is to add methods to objects within the constructor. However, this approach has performance implications, especially when creating many instances of an object.

Let’s take a look at the following code:

function Player(name) {
  this.name = name;

  this.greet = function() {
    console.log("Hello, " + this.name);
  };
}

Every time a new Player is created, a new greet function is also created in memory for that instance. If we create thousands of Player instances, we’ll have thousands of greet functions in memory.

A Better Approach: Prototypes

JavaScript provides prototypes, a mechanism allowing all instances of an object to share its methods, thus conserving memory. Instead of defining methods inside the constructor, we should attach them to the constructor’s prototype. This way, the methods are defined once on the prototype and are shared among all instances, rather than being redefined for each instance.

function Player(name) {
  this.name = name;
}

Player.prototype.greet = function() {
  console.log("Hello, " + this.name);
};

Now, no matter how many Player instances are created, there is only one greet method in memory, shared by all instances. This approach is more memory-efficient and is considered a best practice for defining methods that should be common to all instances.

Another Better Approach: Class

The issue can be also elegantly addressed using JavaScript’s class syntax, introduced in ECMAScript 2015 (ES6). The class syntax provides a clearer, more concise way to create objects and handle inheritance in JavaScript, making it easier to define methods that are shared across all instances of a class.

✨ I plan to publish an article focused on Object-Oriented Programming (OOP) in JavaScript in the future so stay tuned.

Using Class Syntax for Shared Methods

When you define methods within a class, JavaScript automatically places these methods on the class’s prototype rather than duplicating them for each instance. This means that all instances of the class share the same method definitions, conserving memory and improving performance, similar to the prototype-based approach but with a more modern and readable syntax.

Here’s how we can improve the issue using the class syntax:

class Player {
  constructor(name) {
    this.name = name;
  }

  greet() {
    console.log(`Hello, ${this.name}`);
  }
}

The Player class has a constructor where the instance property name is defined.

Moreover, the greet method is defined within the class body but outside of the constructor. JavaScript automatically assigns this method to Player’s prototype, meaning greet is shared among all Player instances.

By doing so, just like with prototype-based methods above, defining methods in a class body avoids the memory overhead of redefining functions for each object instance.

Conclusion

Closures are a fundamental aspect of JavaScript that enables powerful and flexible coding patterns. By grasping how closures work, we can create more efficient coding solutions and optimise performance.

Whether you are dealing with asynchronous operations, event handlers, or state updates, closures provide a great toolset for maintaining access to necessary variables and ensuring your code remains clean and effective.

Understanding and utilizing closures can elevate your development skills, leading to better, more maintainable JavaScript and React applications.

I hope you liked this article, and if you have any questions, please feel free to reach out to me 🤩