Closures are a confusing JavaScript concept to learn, because it's hard to see how they're actually used.

Unlike other concepts such as functions, variables, and objects, you don't always use closures conscientiously and directly. You don't say: Oh! Here I will use a closure as a solution.

But at the same time, you might have already used this concept a hundred times. Learning about closures is more about identifying when one is being used rather than learning a new concept.

What is a closure in JavaScript?

You have a closure when a function reads or modifies the value of a variable defined outside its context.

const value = 1
function doSomething() {
    let data = [1,2,3,4,5,6,7,8,9,10,11]
    return data.filter(item => item % value === 0)
}

Here the function doSomething uses the variable value. But also the function item => item % value === 0 can then be written like this:

function(item){
    return item % value === 0
}

You use the value of the variable value that was defined outside of the function itself.

Functions can access values out of context

As in the previous example, a function can access and use values that are defined outside its "body" or context, for example:

let count = 1
function counter() {
    console.log(count)
}
counter() // print 1
count = 2
counter() // print 2

This allows us to modify the value of the count variable from anywhere in the module. Then when the counter function is called, it will know how to use the current value.

Why do we use functions?

But why do we use functions in our programs? Certainly it is possible – difficult, but possible – to write a program without using functions we define. So why do we create proper functions?

Imagine a piece of code that does something wonderful, whatever, and is made up of X number of lines.

/* My wonderful piece of code */

Now suppose you must use this wonderful piece of code in various parts of your program, what would you do?.

The "natural" option is to put this piece of code together into a set that can be reusable, and that reusable set is what we call a function. Functions are the best way to reuse and share code within a program.

Now, you can use your function as many times as possible. And, ignoring some particular cases, calling your function N times is the same as writing that wonderful piece of code N times. It is a simple replacement.

But where is the closure?

Using the counter example, let's consider that as the wonderful piece of code.

let count = 1
function counter() {
    console.log(count)
}
counter() // print 1

Now, we want to reuse it in many parts, so we will "wrap" it in a function.

function wonderfulFunction() {
    let count = 1
    function counter() {
        console.log(count)
    }
    counter() // print 1
}

Now what do we have? A function: counter that uses a value that was declared outside it count. And a value: count that was declared in the wonderfulFunction function scope but that is used inside the counter function.

That is, we have a function that uses a value that was declared outside its context: a closure.

Simple, isn't it? Now, what happens when the function wonderfulFunction is executed? What happens to the variable count and the function counter once the parent function is executed?

The variables and functions declared in its body "disappear" (garbage collector).

Now, let's modify the example a bit:

function wonderfulFunction() {
    let count = 1
    function counter() {
        count++
        console.log(count)
    }
   setInterval(counter, 2000)
}
wonderfulFunction()

What will happen now to the variable and function declared inside wonderfulFunction?

In this example, we tell the browser to run counter every 2 seconds. So the JavaScript engine must keep a reference to the function and also to the variable that is used by it. Even after the parent function wonderfulFunction finishes its execution cycle, the function counter and the value count will still "live".

This "effect" of having closures occurs because JavaScript supports the nesting of functions. Or in other words, functions are first class citizens in the language and you can use them like any other object: nested, passed as an argument, as a value of return, and so on.

What can I do with closures in JavaScript?

Immediately-invoked Function Expression (IIFE)

This is a technique that was used a lot in the ES5 days to implement the "module" design pattern (before this was natively supported). The idea is to "wrap" your module in a function that is immediately executed.

(function(arg1, arg2){
...
...
})(arg1, arg2)

This lets you use private variables that can only be used by the module itself within the function – that is, it's allowed to emulate the access modifiers.

const module = (function(){
    function privateMethod () {
    }
    const privateValue = "something"
    return {
      get: privateValue,
      set: function(v) { privateValue = v }
    }
})()

var x = module()
x.get() // "something"
x.set("Another value")
x.get() // "Another Value"
x.privateValue //Error

Function Factory

Another design pattern implemented thanks to closures is the “Function Factory”. This is when functions create functions or objects, for example, a function that allows you to create user objects.

const createUser = ({ userName, avatar }) => ({
      id: createID(),
      userName,
      avatar,
      changeUserName (userName) {
        this.userName = userName;
        return this;
      },
      changeAvatar (url) {
        // execute some logic to retrieve avatar image
        const newAvatar = fetchAvatarFromUrl(url)
        this.avatar = newAvatar
        return this
      }
    });

        console.log(createUser({ userName: 'Bender', avatar: 'bender.png' }));

    {
      "id":"17hakg9a7jas",
      "avatar": "bender.png",
      "userName": "Bender",
      "changeUsername": [Function changeUsername]
      "changeAvatar": [Function changeAvatar]

    }
    */c

And using this pattern you can implement an idea from functional programming called currying.

Currying

Currying is a design pattern (and a characteristic of some languages) where a function is immediately evaluated and returns a second function. This pattern lets you execute specialization and composition.

You create these "curried" functions using closures, defining and returning the inner function of the closure.

function multiply(a) {

    return function (b) {
        return function (c)  {
            return a * b * c
        }
    }
}
let mc1 = multiply(1);
let mc2 = mc1(2);
let res = mc2(3);
console.log(res);

let res2 = multiply(1)(2)(3);
console.log(res2);

These types of functions take a single value or argument and return another function that also receives an argument. It is a partial application of the arguments. It is also possible to rewrite this example using ES6.

let multiply = (a) => (b) => (c) => {

    return a * b * c;
}

let mc1 = multiply(1);
let mc2 = mc1(2);
let res = mc2(3);
console.log(res);

let res2 = multiply(1)(2)(3);
console.log(res2);

Where can we apply currying? In composition, let's say you have a function that creates HTML elements.

function createElement(element){
    const el = document.createElement(element)
    return function(content) {
        return el.textNode = content
    }
}

const bold = crearElement('b')
const italic = createElement('i')
const content = 'My content'
const myElement  = bold(italic(content)) // <b><i>My content</i></b>

Event Listeners

Another place you can use and apply closures is in event handlers using React.

Suppose you are using a third party library to render the items in your data collection. This library exposes a component called RenderItem that has only one available prop onClick. This prop does not receive any parameters and does not return a value.

Now, in your particular app, you require that when a user clicks on the item the app displays an alert with the item's title. But the onClick event that you have available does not accept arguments – so what can you do? Closures to the rescue:

// Closure
// with es5
function onItemClick(title) {
    return function() {
      alert("Clicked " + title)
    }
}
// with es6
const onItemClick = title => () => alert(`Clcked ${title}`)

return (
  <Container>
{items.map(item => {
return (
   <RenderItem onClick={onItemClick(item.title)}>
    <Title>{item.title}</Title>
  </RenderItem>
)
})}
</Container>
)

In this simplified example we create a function that receives the title that you want to display and returns another function that meets the definition of the function that RenderItem receives as a prop.

Conclusion

You can develop an app without even knowing that you are using closures. But knowing that they exist and how they really work unlocks new possibilities when you're creating a solution.

Closures are one of those concepts that can be hard to understand when you're starting out. But once you know you're using them and understand them, it allows you to increase your tools and advance your career.

🐦 Follow me on Twitter ✉️ Join to the newsletter ❤️ Support my work

There is a reason why it can be difficult to make sense of closures—because they are often taught backwards. You may have been taught what a closures is, but you might not understand how they are useful to the average developer or within your own code.

So why do closures matter in our day-to-day JavaScript code?

Instead of seeing closures as a topic to be memorized for some sort of pop quiz, let's see what series of steps can lead us to seeing a closure in the first place. Once we see what they are, we will uncover why closures are worthwhile for you to know and take advantage of in your JavaScript code.

Seeing a closure in the wild ?

Let's say we are making an app clone of the blogging site Medium, and we want each user to be able to like different posts.

Whenever a user clicks on the like button, its value will be incremented by one each time.

Think of it like the Medium clap button:

The function that will handle increasing the count by 1 each time is called handleLikePost and we are keeping track of the number of likes with a variable named likeCount:

// global scope
let likeCount = 0;

function handleLikePost() {
  // function scope
  likeCount = likeCount + 1;
}

handleLikePost();
console.log("like count:", likeCount); // like count: 1

Whenever a user likes a post, we call handleLikePost and it increments our likeCount by 1.

And this works because we know that functions can access variables outside of themselves.

In other words, functions can access any variables defined in any parent scope.

There's a problem with this code, however. Since likeCount is in the global scope, and not in any function, likeCount is a global variable. Global variables can be used (and changed) by any other bit of code or function in our app.

For example, what if after our function, we mistakenly set our likeCount to 0?

let likeCount = 0;

function handleLikePost() {
  likeCount = likeCount + 1;
}

handleLikePost();
likeCount = 0;
console.log("like count:", likeCount); // like count: 0

Naturally, likeCount can never be incremented from 0.

When only one function needs a given piece of data, it just needs to exist locally, that is, within that function.

Now let's bring likeCount within our function:

function handleLikePost() {
  // likeCount moved from global scope to function scope
  let likeCount = 0;
  likeCount = likeCount + 1;
}

Note that there's a shorter way to write the line where we increment likeCount. Instead of saying likeCount is equal to previous value of likeCount and add one like this, we can just use the += operator like so:

function handleLikePost() {
  let likeCount = 0;
  likeCount += 1;
}

And for it to work as before and get like count's value, we also need to bring our console.log into the function as well.

function handleLikePost() {
  let likeCount = 0;
  likeCount += 1;
  console.log("like count:", likeCount);
}

handleLikePost(); // like count: 1

And it still works properly as before.

So now users should be able to like a post as many times as they want, so let's call handleLikePost a few more times:

handleLikePost(); // like count: 1
handleLikePost(); // like count: 1
handleLikePost(); // like count: 1

When we run this code, however, there's a problem.

We would expect to see the likeCount keep increasing, but we just see 1 each time. Why is that?

Take a second, look at our code and try to explain why our likeCount is no longer being incremented.

Let's look at our handleLikePost function and how it's working:

function handleLikePost() {
  let likeCount = 0;
  likeCount += 1;
  console.log("like count:", likeCount);
}

Every time we use it, we are recreating this likeCount variable, which is given an initial value of 0.

No wonder we can't keep track of the count between function calls! It keeps being set to 0 each time, then it's incremented by 1, after which the function is finished running.

So we're stuck here. Our variable needs to live inside of the handleLikePost function, but we can't preserve the count.

We need something that allows us to preserve or remember the likeCount value between function calls.

What if we tried something that may look a little strange at first—what if we tried putting another function in our function:

function handleLikePost() {
  let likeCount = 0;
  likeCount += 1;
  function() {

  }
}

handleLikePost();

Here we're going to name this function addLike. The reason? Because it will be responsible for incrementing the likeCount variable now.

And note that this inner function doesn't have to have a name. It can be an anonymous function. In most cases, it is. We're just giving it a name so we can more easily talk about it and what it does.

addLike will now be responsible for increasing our likeCount, so we'll move the line where we increment by 1 into our inner function.

function handleLikePost() {
  let likeCount = 0;
  function addLike() {
    likeCount += 1;
  }
}

What if we were to call this addLike function in handleLikePost?

All that would happen is that addLike would increment our likeCount, but still the likeCount variable would be destroyed. So again, we lose our value and the result is 0.

But instead of calling addLike within its enclosing function, what if we called it outside of the function? This seems even stranger. And how would we do that?

We know at this point that functions return values. For example, we could return our likeCount value at the end of handleLikePost to pass it to other parts of of our program:

function handleLikePost() {
  let likeCount = 0;
  function addLike() {
    likeCount += 1;
  }
  addLike();
  return likeCount;
}

But instead of doing that, let's return likeCount within addLike and then return the addLike function itself:

function handleLikePost() {
  let likeCount = 0;
  return function addLike() {
    likeCount += 1;
    return likeCount;
  };
  // addLike();
}

handleLikePost();

Now this may look bizarre, but this is allowed in JS. We can use functions like any other value in JS. That means a function can be returned from another function. By returning the inner function, we can call it from outside of its enclosing function.

But how would we do that? Think about this for a minute and see if you can figure it out...

First, to better see what's happening, let's console.log(handleLikePost) when we call it and see what we get:

function handleLikePost() {
  let likeCount = 0;
  return function addLike() {
    likeCount += 1;
    return likeCount;
  };
}

console.log(handleLikePost()); // ƒ addLike()

Unsurprisingly, we get the addLike function logged. Why? Because we're returning it, after all.

To call it, couldn't we just put it in another variable? As we just said, functions can be used like any other value in JS. If we can return it from a function, we can put it in a variable too. So let's put it in a new variable called like:

function handleLikePost() {
  let likeCount = 0;
  return function addLike() {
    likeCount += 1;
    return likeCount;
  };
}

const like = handleLikePost();

And finally, let's call like. We'll do it a few times and console.log each result:

function handleLikePost() {
  let likeCount = 0;
  return function addLike() {
    likeCount += 1;
    return likeCount;
  };
}

const like = handleLikePost();

console.log(like()); // 1
console.log(like()); // 2
console.log(like()); // 3

Our likeCount is finally preserved! Every time we call like, the likeCount is incremented from its previous value.

So what in the world happened here? Well, we figured out how to call the addLike function from outside the scope in which it was declared. We did that by returning the inner function from the outer one and storing a reference to it, named like, to call it.

How a closure works, line-by-line ?

So that was our implementation, of course, but how did we preserve the value of likeCount between function calls?

function handleLikePost() {
  let likeCount = 0;
  return function addLike() {
    likeCount += 1;
    return likeCount;
  };
}

const like = handleLikePost();

console.log(like()); // 1

1. The handleLikePost outer function is executed, creating an instance of the inner function addLike; that function closes over the variable likeCount, which is one scope above.
2. We called the addLike function from outside the scope in which it was declared. We did that by returning the inner function from the outer one and storing a reference to it, named like, to call it.
3. When the like function finishes running, normally we would expect all of its variables to be garbage collected (removed from memory, which is an automatic process that the JS compiler does). We'd expect each likeCount to go away when the function is done, but they don't.

What is that reason? Closure.

Since the inner function instances are still alive (assigned to like), the closure is still preserving the countLike variables.

You would think that having a function written in another function, would just be like a function written in the global scope. But it's not.

This is why closure makes functions so powerful, because it is a special property that isn't present in anything else in the language.

The lifetime of a variable

To better appreciate closures, we have to understand how JavaScript treats variables that are created. You might have wondered what happens to variables when you close your page or go to another page within an app. How long do variables live?

Global variables live until the program is discarded, for example when you close the window. They are around for the life of the program.

However, local variables have short lives. They are created when the function is invoked, and deleted when the function is finished.

So before, where likeCount was just a local variable, when the function was run. The likeCount variable was created at the beginning of the function and then destroyed once it finished executing.

Closures are not snapshots - they keep local variables alive

It's sometimes stated that JavaScript closures are similar to snapshots, a picture of our program at certain point in time. This is a misconception that we can dispel by adding another feature to our like button functionality.

Let's say that on some rare occasions, we want to allow users to 'double like' a post and increment the likeCount by 2 at a time instead of 1.

How would would we add this feature?

Another way to pass values to a function is of course through arguments, which operate just like local variables.

Let's pass in an argument called step to the function, which will allow us to provide a dynamic, changeable value to increment our count by instead of the hard-coded value 1.

function handleLikePost(step) {
  let likeCount = 0;
  return function addLike() {
    likeCount += step;
    // likeCount += 1;
    return likeCount;
  };
}

Next, let's try making a special function that will allow us to double like our posts, doubleLike. We'll pass in 2 as our step value to make it and then try calling both of our functions, like and doubleLike:

function handleLikePost(step) {
  let likeCount = 0;
  return function addLike() {
    likeCount += step;
    return likeCount;
  };
}

const like = handleLikePost(1);
const doubleLike = handleLikePost(2);

like(); // 1
like(); // 2

doubleLike(); // 2 (the count is still being preserved!)
doubleLike(); // 4

We see the likeCount is also being preserved for doubleLike.

What's happening here?

Each instance of the inner addLike function closes over both the likeCount and step variables from its outer handleLikePost function's scope. step remains the same over time, but the count is updated on each invocation of that inner function. Since closure is over the variables and not just snapshots of the values, these updates are preserved between function calls.

So what does this code show to us—the fact that we can pass in dynamic values to change the result of our function? That they are still alive! Closures keep local variables alive from functions that should have destroyed them a long time ago.

In other words, they are not static and unchanging, like a snapshot of the closed-over variables value at one point in time—closures preserve the variables and provide an active link to them. As a result, we can use closures can observe or make updates to these variables over time.

What is a closure, exactly?

Now that you see how a closure is useful, there are two criteria for something to be a closure, both of which you've seen here:

1. Closures are a property of JavaScript functions, and only functions. No other data type has them.
2. To observe a closure, you must execute a function in a different scope than where that function was originally defined.

Why should you know closures?

Let's answer the original question we set out to answer. Based off of what we've seen, pause and take a stab at answering this question. Why should we care about closures as JS developers?

Closures matter for you and your code because they allow you to 'remember' values, which is a very powerful and unique feature in the language which only functions possess.

We saw it right here in this example. After all, what use is a like count variable that doesn't remember likes? You'll encounter this often in your JS career. You need to hold onto some value somehow and likely keep it separate from other values. What do you use? A function. Why? To keep track of data over time with a closure.

And with that, you're already a step ahead other developers.

Become a Professional React Developer

React is hard. You shouldn't have to figure it out yourself.

I've put everything I know about React into a single course, to help you reach your goals in record time:

Introducing: The React Bootcamp

It’s the one course I wish I had when I started learning React.

Click below to try the React Bootcamp for yourself:

Click to get started

Closures – many of you JavaScript devs have probably heard this term before. When I started my journey with JavaScript, I encountered closures often. And I think they're one of the most important and interesting concepts in JavaScript.

You don't think they're interesting? This often happens when you don’t understand a concept – you don’t find it interesting. (I don’t know if this happens to you or not, but this is the case with me).

So in this article, I will try to make closures interesting for you.

Before going into the world of closures, let’s first understand lexical scoping. If you already know about it, skip the next part. Otherwise jump into it to better understand closures.

Lexical Scoping

You may be thinking – I know local and global scope, but what the heck is lexical scope? I reacted the same way when I heard this term. Not to worry! Let’s take a closer look.

It’s simple like other two scopes:

function greetCustomer() {
    var customerName = "anchal";
    function greetingMsg() {
      console.log("Hi! " + customerName); // Hi! anchal
    }
   greetingMsg();
}

You can see from the above output that the inner function can access the outer function's variable. This is lexical scoping, where the scope and value of a variable is determined by where it is defined/created (that is, its position in the code). Got it?

I know that last bit might have confused you. So let me take you deeper. Did you know that lexical scoping is also known as static scoping? Yes, that's its other name.

There is also dynamic scoping, which some programming languages support. Why have I mentioned dynamic scoping? Because it can help you better understand lexical scoping.

Let’s look at some examples:

function greetingMsg() {
  console.log(customerName);// ReferenceError: customerName is not defined
}

function greetCustomer() {
   var customerName = "anchal";
   greetingMsg();
}

greetCustomer();

Do you agree with the output? Yes, it will give a reference error. This is because both functions don’t have access to each other’s scope, as they are defined separately.

Let’s look at another example:

function addNumbers(number1) {
  console.log(number1 + number2);
}

function addNumbersGenerate() {
  var number2 = 10;
  addNumbers(number2);
}

addNumbersGenerate();

The above output will be 20 for a dynamically scoped language. Languages that support lexical scoping will give referenceError: number2 is not defined. Why?

Because in dynamic scoping, searching takes place in the local function first, then it goes into the function that called that local function. Then it searches in the function that called that function, and so on, up the call stack.

Its name is self explanatory – “dynamic” means change. The scope and value of variable can be different as it depends on from where the function is called. The meaning of a variable can change at runtime.

Got the gist of dynamic scoping? If yes, then just remember that lexical scoping is its opposite.

In lexical scoping, searching takes place in the local function first, then it goes into the function inside which that function is defined. Then it searches in the function inside which that function is defined and so on.

So, lexical or static scoping means the scope and value of a variable is determined from where it is defined. It doesn’t change.

Let’s again look at the above example and try to figure out the output on your own. Just one twist – declare number2 at the top:

var number2 = 2;
function addNumbers(number1) {
  console.log(number1 + number2);
}

function addNumbersGenerate() {
  var number2 = 10;
  addNumbers(number2);
}

addNumbersGenerate();

Do you know what the output will be?

Correct – it’s 12 for lexically scoped languages. This is because first, it looks into an addNumbers function (innermost scope) then it searches inwards, where this function is defined. As it gets the number2 variable, meaning the output is 12.

You may be wondering why I have spent so much time on lexical scoping here. This is a closure article, not one about lexical scoping. But if you don’t know about lexical scoping then you will not understand closures.

Why? You will get your answer when we look at the definition of a closure. So let’s get into the track and get back to closures.

What is a Closure?

Let’s look at the definition of a closure:

Closure is created when an inner function has access to its outer function variables and arguments. The inner function has access to –

1. Its own variables.
2. Outer function's variables and arguments.
3. Global variables.

Wait! Is this the definition of a closure or lexical scoping? Both definitions look the same. How they are different?

Well, that's why I defined lexical scoping above. Because closures are related to lexical/static scoping.

Let’s again look at its other definition that will tell you how closures are different.

Closure is when a function is able to access its lexical scope, even when that function is executing outside its lexical scope.

Or,

Inner functions can access its parent scope, even after the parent function is already executed.

Confused? Don't worry if you haven't yet gotten the point. I have examples to help you better understand. Let’s modify the first example of lexical scoping:

function greetCustomer() {
  const customerName = "anchal";
  function greetingMsg() {
    console.log("Hi! " + customerName);
  }
  return greetingMsg;
}

const callGreetCustomer = greetCustomer();
callGreetCustomer(); // output – Hi! anchal

The difference in this code is that we are returning the inner function and executing it later. In some programming languages, the local variable exists during the function’s execution. But once the function is executed, those local variables don’t exist and they will not be accessible.

Here, however, the scene is different. After the parent function is executed, the inner function (returned function) can still access the parent function's variables. Yes, you guessed right. Closures are the reason.

The inner function preserves its lexical scope when the parent function is executing and hence, later that inner function can access those variables.

To get a better feel for it, let’s use the dir() method of the console to look into the list of the properties of callGreetCustomer:

console.dir(callGreetCustomer);

From the above image, you can see how the inner function preserves its parent scope (customerName) when greetCustomer() is executed. And later on, it used customerName when callGreetCustomer() was executed.

I hope this example helped you better understand the above definition of a closure. And maybe now you find closures a bit more fun.

So what next? Let’s make this topic more interesting by looking at different examples.

Examples of closures in action

function counter() {
  let count = 0;
  return function() {
    return count++;
  };
}

const countValue = counter();
countValue(); // 0
countValue(); // 1
countValue(); // 2

Every time you call countValue, the count variable value is incremented by 1. Wait – did you think that the value of count is 0?

Well, that would be wrong as a closure doesn’t work with a value. It stores the reference of the variable. That’s why, when we update the value, it reflects in the second or third call and so on as the closure stores the reference.

Feeling a bit clearer now? Let’s look at another example:

function counter() {
  let count = 0;
  return function () {
    return count++;
  };
}

const countValue1 = counter();
const countValue2 = counter();
countValue1();  // 0
countValue1();  // 1
countValue2();   // 0
countValue2();   // 1

I hope you guessed the right answer. If not, here is the reason. As countValue1 and countValue2, both preserve their own lexical scope. They have independent lexical environments. You can use dir() to check the [[scopes]] value in both the cases.

Let’s look at a third example.

This one's a bit different. In it, we have to write a function to achieve the output:

const addNumberCall = addNumber(7);
addNumberCall(8) // 15
addNumberCall(6) // 13

Simple. Use your newly-gained closure knowledge:

function addNumber(number1) {
  return function (number2) {
    return number1 + number2;
  };
}

Now let’s look at some tricky examples:

function countTheNumber() {
  var arrToStore = [];
  for (var x = 0; x < 9; x++) {
    arrToStore[x] = function () {
      return x;
    };
  }
  return arrToStore;
}

const callInnerFunctions = countTheNumber();
callInnerFunctions[0]() // 9
callInnerFunctions[1]() // 9

Every array element that stores a function will give you an output of 9. Did you guess right? I hope so, but still let me tell you the reason. This is because of the closure's behavior.

The closure stores the reference, not the value. The first time the loop runs, the value of x is 0. Then the second time x is 1, and so on. Because the closure stores the reference, every time the loop runs it's changing the value of x. And at last, the value of x will be 9. So callInnerFunctions[0]() gives an output of 9.

But what if you want an output of 0 to 8? Simple! Use a closure.

Think about it before looking at the solution below:

function callTheNumber() {
  function getAllNumbers(number) {
    return function() {
      return number;
    };
  }
  var arrToStore = [];
  for (var x = 0; x < 9; x++) {
    arrToStore[x] = getAllNumbers(x);
  }
  return arrToStore;
}

const callInnerFunctions = callTheNumber();
console.log(callInnerFunctions[0]()); // 0
console.log(callInnerFunctions[1]()); // 1

Here, we have created separate scope for each iteration. You can use console.dir(arrToStore) to check the value of x in [[scopes]] for different array elements.

That’s it! I hope you can now say that you find closures interesting.

To read my other articles, check out my profile here.