<![CDATA[ closure - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ https://cdn.freecodecamp.org/universal/favicons/favicon.png <![CDATA[ closure - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ Eleventy Sun, 24 May 2026 16:30:24 +0000 60 <![CDATA[ How Closures Work in JavaScript: A Handbook for Developers ]]> https://www.freecodecamp.org/news/how-closures-work-in-javascript-a-handbook-for-developers/ 6925c63dff3af82fd3477d27 Fri, 16 Jan 2026 08:00:00 +0000 If you're learning JavaScript, you've probably heard the term "closure" at some point. In many developers' experience, just hearing this word can trigger anxiety. In nearly 17 years of programming experience, I've noticed that closures are one of the most intimidating topics for JavaScript developers, even though they shouldn't be.

The main goal of this handbook is to remove that fear. By the end of this guide, you should be able to confidently say, "I’m not afraid of closures anymore!"

Closures aren't actually that complicated at all when you break them down. They just might seem harder to grasp while you don't understand them clearly. Many articles or tutorials don't explain the topic deeply, which leaves you confused, asking questions like, "What exactly is a closure?" or "What does it really mean?"

Throughout this handbook, I'll walk you through several examples step by step. If you stick with this guide until the end, I promise – all your confusion about closures should disappear.

Here’s What We’ll Cover

  1. Prerequisites

  2. Project Setup Before Learning Closures

  3. Functions and Parameters - The Basics

  4. Accessing Variables Without Parameters

  5. Understanding Scope and Lexical Scoping

  6. What is a Closure?

  7. Functions as Objects

  8. The Function-Parent Relationship

  9. Nested Functions and Closures

  10. Refining the Example

  11. Creating Private Properties with Closures

  12. The Role of Closures in Privacy

  13. Understanding Closure Mechanics

  14. Closures and Enclosing Scopes

  15. Practical Example - Self-Contained Closures

  16. The Difference Between var and let

  17. Understanding Closures Through a Practical Stopwatch Example

  18. Closures in Asynchronous Code

  19. Practical Example: API Requests with Closures

  20. Advanced Example - Closures in Loops

  21. Summary and Key Takeaways

  22. Final Words

Prerequisites

To follow along and get the most out of this guide, you should have:

  1. Basic JavaScript (ES6-style) knowledge

  2. Familiarity with browser developer tools

  3. Comfort with asynchronous code (promises)

  4. Basic ability to use the terminal/command line

  5. Familiarity with a code editor like VS Code – Live Server extension (for running HTML files locally)

I’ve also created a video to go along with this article. If you’re the type who likes to learn from video as well as text, you can check it out below.

Project Setup Before Learning Closures

Closures are an amazing concept in JavaScript. But if you jump into the code without preparation, they can feel a bit intimidating.

So before we start exploring closures, let's set up a simple, clean project where you can test each example comfortably. Once this setup is done, you won't need to repeat it again and again throughout the article. So follow along carefully and you'll prepare everything at once.

Create a New Project Folder

Open your terminal and run:

mkdir closure
cd closure

This folder will contain your main HTML file and all the JavaScript examples.

Create the index.html File

Now create the HTML file:

touch index.html

Open index.html and add the following code:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <title>Closure Tutorial | LogicBase Labs</title>
    </head>
    <body>
        <script src="./script/example-1.js"></script>
        <script src="./script/example-2.js"></script>
        <script src="./script/example-3.js"></script>
        <script src="./script/example-4.js"></script>
        <script src="./script/example-5.js"></script>
        <script src="./script/example-6.js"></script>
        <script src="./script/example-7.js"></script>
    </body>
</html>

Why so many <script> tags?

Good question! In this tutorial, you'll explore closures in 7 different ways. Each example will live in its own JavaScript file, so things stay clean and beginner-friendly. If you tried to put everything inside one file, the outputs would get mixed up and confusing. That's why you're loading each example separately.

Create the script Folder + Seven Example Files

Let's create a folder named script:

mkdir script
cd script

Now create the seven example files:

touch example-1.js
touch example-2.js
touch example-3.js
touch example-4.js
touch example-5.js
touch example-6.js
touch example-7.js

You'll write and test each closure example inside these files.

Very Important Note:

If all 7 files run at the same time, your console output will get mixed up. You won't understand which message came from which example.

So here's the rule:

  • When working on example-1.js, comment out the rest.

  • When working on example-3.js, uncomment that one only, and comment out the others.

Example:

<!-- <script src="./script/example-1.js"></script> -->
<!-- <script src="./script/example-2.js"></script> -->
<script src="./script/example-3.js"></script>
<!-- <script src="./script/example-4.js"></script> -->
<!-- <script src="./script/example-5.js"></script> -->
<!-- <script src="./script/example-6.js"></script> -->
<!-- <script src="./script/example-7.js"></script> -->

This keeps your output clean, clear, and conflict-free.

Run the Project

Open Live Server from VS Code and you'll see: http://127.0.0.1:5500/closure/index.html

This is your working route. Inside this project, you'll explore the full world of closures step by step. Now you're ready to dive into closures and learn what they are, how they work, and why closures are one of the most powerful concepts in JavaScript.

Functions and Parameters – The Basics

So now you will mainly work on the example-1.js file. Listen, throughout this entire handbook, you will first write the full code, and then we’ll go line by line to understand the breakdown in detail. There's nothing to worry about: we will uncover every single thing in its full depth.

Full code: example-1.js

// example-1.js
function sum(num1, num2) {
    return num1 + num2;
}
console.log(sum(2, 3));

Usually, when you want to use an outside variable inside a function, you pass it as a parameter. For example, consider a function called sum:

function sum(num1, num2)

Here, two numbers are taken as parameters. To add these numbers and return the result:

return num1 + num2;

To see the output:

console.log(sum(2, 3));

The output will be 5. Simple, right?

Accessing Variables Without Parameters

Full code: example-1.js

var num1 = 2;
var num2 = 3;

function sum() {
    return num1 + num2;
}

console.log(sum());

But in JavaScript, there's a way to do the same thing without passing parameters. Let's remove the parameters from the sum function. Instead, you'll define two variables in the global scope:

var num1 = 2;
var num2 = 3;

Now, when you call sum(), the output will still be 5.

The question is: “how does JavaScript do this?” It seems strange, right? Inside a function, you're using variables that don't actually belong to that function – they exist outside in the wider environment where the function was created. In simple terms, the function is using variables from its parent scope.

Understanding Scope and Lexical Scoping

This concept relates to one of the most fundamental principles in JavaScript: everything from a parent is accessible to the child. If there were nested functions inside this function, even the deepest child function could access variables like num1 and num2 from the parent. The parent's variables are fully accessible to the child, but nothing from the child can be accessed by the parent.

I’ve already covered this topic in a detailed video on JavaScript Scope on the LogicBase Labs YouTube channel. If you'd like to revisit the concept or get a quick refresher, you can watch the video below.

For example, if you define a new variable inside the sum function, it cannot be accessed from outside the function. This is the core idea of scope. This system of scope is theoretically called Lexical Scoping. Since today's topic is Closures, understanding scope is essential, as closures and scope are deeply connected.

According to lexical scoping, a child function can access its parent's variables, but a parent cannot access the child's. This isn't random – it's a specific convention or guideline in JavaScript.

What is a Closure?

The word "closure" literally means a "bond" or "enclosure." Think of it like keeping a variable safely locked away, just like storing something inside a box.

Even though the box is closed, you can still use its contents when needed. This is why it's called a closure: because you keep a function's variables enclosed in such a way that, even if the outside world cannot access them directly, the function itself can still use them whenever required.

Functions as Objects

In JavaScript, whenever you write a function, the function is actually treated as an object. Every function in JavaScript works as an object. Just as you can console.log an object to see it, you can also inspect a function.

Let's print our sum function:

console.dir(sum);

Notice that you're not calling the function. Rather, you're just printing its body. You use dir instead of log because console.log only shows the function body, while console.dir displays the function as an object, letting you see each of its properties one by one. You can think of it as an upgraded version of console.log.

Looking at the output, you'll see an object. Expanding it reveals many properties, like name, length, prototype, and more. At the very bottom, there's a property called Scopes. Inside Scopes, there's a section named Global containing further details. The Scopes property is what we’ll mainly focus on here.

Nested Function and Closure

The Function-Parent Relationship

Notice something here: the sum function has its own world, right? So why is it still referencing the global scope?

Every function actually maintains a connection with its parent environment. It doesn't just live in its own world – it keeps a link to the environment where it was created. Simply put, it always holds a reference to its parent.

Why does it do this? Because if anything changes in the parent environment (like a variable's value or the need to use it inside the function), the function can still access it.

This whole process is the core concept of a closure. A function keeps track of the variables it uses from outside its own scope by closing over its parent, and its parent's parent – essentially the entire scope chain above it – holds them as references.

That's why this example is actually the simplest form of a closure. The sum function itself is a closure because it has captured some variables from its outer environment and can use them whenever needed.

Even though you often see closures explained with examples where "a function is inside another function," the fundamental idea starts here: “any function that retains access to variables from its outer scope is, in essence, a closure.”

Nested Functions and Closures

Full code: example-1.js

// example-1.js
var num1 = 2;
var num2 = 3;

function sum() {
    return function () {
        return num1 + num2;
    };
}

var myFunc = sum();

console.dir(myFunc);

You can understand this even more clearly by tweaking the previous sum function. Instead of directly returning a value, you'll have the sum function return another function:

return function () {};

And inside this inner function, you write:

return num1 + num2;

So what does this mean? The sum function is no longer returning a value directly. Instead, it's returning a function.

Now, create another variable called myFunc:

var myFunc = sum();

You called the sum function, and whatever it returned (the inner function) is now stored in myFunc. In other words, myFunc is essentially the inner function returned by sum.

If you print myFunc to the console:

console.dir(myFunc);

You'll see num1 and num2 listed as variables in the output. This function is still holding onto its global environment. Even though it's an inner function, it's still connected to the global scope and maintains the same global references as before.

Nested Function and Closure

Refining the Example

Full code: example-1.js

// example-1.js
var num1 = 2;

function sum() {
    var num2 = 3;
    return function () {
        return num1 + num2;
    };
}

var myFunc = sum();

console.dir(myFunc);

Now, remove the num2 variable from the global scope and define it inside the sum function instead.

Refine the closure

This time, in the browser, you can clearly see something labeled "Closure." In other words, the browser is directly showing that a closure has been created inside this function.

In older versions of Chrome, you would have seen "Closure" in the previous example too. But in the newer versions, it shows as "Global" until a function actually closes over another function. When a function is returned from within another function, that's when the browser displays "Closure." But keep in mind that theoretically, the previous example was also a kind of closure. The difference is just in how the browser presents it.

When you did console.dir(myFunc), you saw that this inner function is using both num1 and num2:

  • num1 is in the global scope

  • num2 is inside the sum function's scope

So what is this inner function doing? It's taking a reference to num1 from the global scope and at the same time taking a reference to num2 from its parent function, sum. In other words, this inner function now carries two worlds within it: one is the global scope, and the other is its parent scope. This is exactly what a closure does: it keeps all the outer scopes it needs "enclosed" so it can use their variables whenever necessary.

In the browser, you can see that inside this closure, num2 exists, while num1 remains in the global scope. So num1 is no longer part of the closure. What does this mean? The function only carries the parts of the environment it actually needs for its execution. Simply put, it takes all the variables it needs, along with their references, as a compact package.

Think of it like the function holding onto references: whenever any of these variables are updated, the function can see those changes because it's still connected to the same references.

If you called myFunc = sum() once and keep calling sum() repeatedly, there's no problem. Each time, a new function will create its own separate scope and keep a reference to that scope. You defined a function and then called it elsewhere. Every time you call that function, it can still access the data from its previous scope. That's because every function preserves all the information from its parent scope as references. This is exactly how a function remembers its outer variables – and this is what a closure is.

Creating Private Properties with Closures

So far, all the examples you've seen were very simple. Now, let's look at a practical example that will help you understand closures better and clear up any confusion.

Think about other programming languages for a minute: when you want to create a private property, what do you usually do? You define a property inside a class and mark it as "private" so that no one can access it directly from outside the class. Then, inside the class, you create one or more public functions (like getters or setters) which allow controlled access to or modification of that property. In other words, you can't touch the property directly from outside – you can only interact with it through specific functions defined inside the class.

In JavaScript, you can achieve the same idea much more simply using closures, entirely in a functional style.

Creating private property

How? Let's see an example. Suppose you have a simple function:

Full code: example-2.js

// example-2.js
function bankAccount(initialBalance) {
    var balance = initialBalance;

    return function () {
        return balance;
    };
}
var account = bankAccount(100000);

console.log(account());
console.dir(account);

function bankAccount(initialBalance) {}

You've named it bankAccount, and it takes the user's initial balance as a parameter.

Inside it, define a variable:

var balance = initialBalance;

So, the user's initial balance is stored internally in a variable called balance. Next, return a function that returns this balance variable. In other words, the balance can only be accessed through this returned function.

Outside, in the global scope, create a variable:

var account = bankAccount(100000);

Here, you called the bankAccount function and passed 100000 as the initial balance. What is this function actually doing? It's returning another function. So now, the account variable holds that returned function.

If you write in the console:

console.log(account());

The output will be 100000.

Private Property Output

But if you try this:

console.log(balance);

it won't work, because the balance variable cannot be accessed from outside.

Error Output

What does this mean? The balance property is protected or private. No one from the outside can directly touch it. To see the balance, you can only call the returned function inside the original function. This is how you keep balance as a private variable and control access to it.

The Role of Closures in Privacy

So, what's the role of the closure here? It's exactly what makes this possible. The inner function is the closure. If you write:

console.dir(account);

You'll see that inside the account function is the returned function.

By taking the output and expanding it, you'll see that the balance variable exists inside the closure. Exactly, right? This means that balance wasn't created inside the account function itself – it was created one scope level up. Yet, you can still access balance from the returned function.

It's similar to the previous example, but this use case is slightly different. Here, you're showing how a private property can be kept secure. Even though you called the inner function from the outside, it still had access to balance within its scope. So, the outer scope cannot directly access balance, but thanks to the closure, you can maintain a reference to it. Even though the function is called from outside, the closure allows you to access the private property in a protected way.

Why protected? Because you're not accessing it directly – you can only see balance through the function call.

💡This is another powerful use case of closures: securing private properties so that they can't be directly accessed from outside, but only through specific functions.

Understanding Closure Mechanics

How Closures Make Decisions

Now, let’s look at another aspect of closures. We’ll revisit our first example.

Previous code: example-1.js

// example-1.js
var num1 = 2;

function sum() {
    var num2 = 3;
    return function () {
        return num1 + num2;
    };
}

var myFunc = sum();

console.dir(myFunc);

In that example, you used a variable called num2 inside the inner function. That's why the function acted as a closure, right?

Full code: example-3.js

// example-3.js
var num1 = 2;
function sum() {
    var num2 = 3;
    return function () {
        return num1;
    };
}
var myFunc = sum();
console.dir(myFunc);

Now, keep the variable but stop using num2 inside the inner function. If you check the output, you'll see that the closure is gone. Why?

Closure Gone Output

It's because num2 isn't used inside the inner function. JavaScript smartly recognizes that this variable isn't needed, so it's not included in the closure. In other words, JavaScript decides on its own: variables that won't be used inside the function, even if they exist in the outer scope, are not included in the closure. Only the variables that the function actually needs become part of the closure.

Full code: example-3.js

// example-3.js
var num1 = 2;
function sum() {
    var num2 = 3;
    var num = 6;
    return function () {
        return num;
    };
}
var myFunc = sum();
console.dir(myFunc);

For example, if you define another variable inside the sum function:

var num = 6;

and do nothing else, there's still no need for a closure. But if you modify the inner function to return num instead of num1, the closure appears again. This time, the closure contains only num. num2 won't be there, but num1 remains because it exists in the global scope. JavaScript preserves this scope to maintain lexical scoping.

Closure with num Output

If you look at the global scope, you can still see num1. That's because you used the var keyword. If you had used let, it wouldn't be visible. The key difference you're noticing is: num1 exists in the global scope, so it remains in the closure's "environment," but if a variable inside the inner function isn't used, it's not included in the closure.

For example, if you use num1, you're accessing the global variable. So what happens now? Will there be a closure? Look, there isn't one. Since num1 exists in the global scope, there's no extra need. The global scope is sufficient, and no separate closure is required. This shows how closures actually work.

No Closure with Global Output

A closure decides which variables need to be kept inside the function and which don't. JavaScript makes this decision automatically. You just need to remember lexical scoping so that outer scope variables can be accessed.

In simple terms, closures make intelligent decisions. Variables used inside the function are kept "inside," variables in outer scopes that aren't used aren't included, and global variables are accessible directly, so there's no need to include them in the closure.

So here, you kept num1, and it exists in the global scope. The function can access it directly from there. But if the inner function used only num – which doesn't exist in its own scope or globally – then a closure would have to be created to carry that variable along.

In short, a closure doesn't wrap everything. It doesn't include variables that are already outside. This is an important point. Another important point is that global scope variables are never included in closures.

Closures and Enclosing Scopes

The Documentation Definition

Often, there's some confusion about when a closure appears and when it just shows global. Even senior interviewers sometimes hesitate to call the global scope a closure at first glance.

If you look at the JavaScript documentation maintained by Mozilla, the 2016 docs highlighted something important.

In the definition, it stated:

"variables that are used locally, but defined in an enclosing scope" (Reference)

This refers to variables that are used locally inside a function but are actually defined in an outer scope. This is key. Only variables that are actually used inside a function are included in the closure. Variables that exist in an outer scope but aren't used inside the function aren't part of the closure.

In simple terms, a closure is a function that remembers its local scope along with the necessary variables from an outer scope, so even if the function is called from outside, it can still access those variables.

The Enclosing Scope Concept

Suppose you have a variable num defined outside, but you use it locally inside the function. That's why the browser shows it as a closure, just like the documentation says.

Full Code: example-3.js

// example-3.js
var num1 = 2;
function sum() {
    var num2 = 3;
    return num1 + num2;
}
console.dir(sum);

But if you don't use the outer variable inside the returned function, what happens? If you removed everything else and just returned num1 + num2, the sum function would work fine. But if you do console.dir(sum), the word "closure" doesn't appear.

Why? Because num2 is local inside the function, and there's no need to include it in a closure. A closure is only needed to use variables from an outer scope. Since this is the very first-level outer scope (meaning the global scope) and it's not inside any function, the sum function is already capturing it in its own scope. So no additional closure is created.

The critical question is: “when does the browser show a closure, and when doesn't it?” The explanation comes from the documentation: "variables that are used locally, but defined in an enclosing scope." Your num1 variable is defined outside but used locally inside. But num1 doesn't have any enclosing scope. Here, an enclosing scope means a scope that wraps around another scope – inside a set of brackets. But num1 is directly in the global scope, not inside any enclosing scope.

Full code: example-3.js

// example-3.js
(function () {
    var num1 = 2;
    function sum() {
        var num2 = 3;
        return num1 + num2;
    }

    console.dir(sum);
})();

If you want to bring this into an enclosing scope, you need to wrap the whole thing inside a function. You can write an anonymous function like this:

function(){}

Then you put everything inside that function and immediately call it. This is known as an Immediately Invoked Function Expression (IIFE for short). It’s basically a function that gets defined and executed at the same time.

When you use an IIFE, everything gets moved into an enclosing scope. The num1 that was previously open in the global scope is now inside this function. So it's now part of an enclosing scope. If you check in the browser and expand it, you see the word "closure."

Closure with Enclosing Scope Output

That's because you've brought the variables into an enclosing scope. The browser now shows it as a closure.

Interpreting the Closure Definition

If someone ever gets confused or disagrees, they might say, "The outer one isn't a closure, it's just the global scope." But theoretically, you can still consider it a closure. Some might insist, "That's a closure," while others may not agree.

The thing is, JavaScript always keeps the global scope intact to maintain lexical scoping. People who disagree might say, "The global scope is just preserved, that's not a closure." And that's fair. But the concept is really the same. If a variable from an outer scope is used or referenced inside a function, it behaves just like a closure. The idea is consistent.

There's a small difference though: the global scope keeps all variables that exist outside any function. That's why some might argue it's not technically a closure. But from a theoretical perspective, it behaves like one, with only minor differences for global variables.

Full code: example-3.js

// example-3.js
var num1 = 2;
function sum() {
    var num2 = 3;
    return num1 + num2;
}

console.dir(sum);

If you didn't use an IIFE and went back to the previous setup, the browser would no longer show it as a closure. And the var num1 is in the global scope.

No Closure with Global Output

If you add another variable:

var num3 = 5;

This num3 isn't used by the sum function, but if you look in the global scope, you can still see it. The browser shows num3 as well.

Global Scope with num3 Output

But a closure only keeps what's necessary. Here, num3 exists because it's part of the global scope. The global object always holds references to its own variables, which is why num3 is visible. This often causes confusion: should you call it a closure or not?

The point is, in the 2016 documentation, the term "enclosing scope" was clearly mentioned. In the current documentation, that phrase is missing. This means they've intentionally avoided that confusion.

The modern definition now says, "closure is the combination of a function bundled together with references to its surrounding state" which is written more concisely compared to before. (Reference)

Here, "state" refers to the lexical environment – that could be the child's environment, the parent's environment, or the entire scope. Based on this definition, a function keeps itself along with any variables it needs to remember, all bundled together. Explaining this clearly in words can be tricky. But you'll see more examples ahead, which will make each use case clear.

Practical Example: Self-Contained Closures

Full code: example-3.js

// example-3.js
(function () {
    var num1 = 2;
    var num2 = 3;

    function sum() {
        return num1 + num2;
    }

    console.log(sum());
    console.dir(sum);
})();

Let's look at another aspect. You're going back to the IIFE function. Here, you have a function called sum that adds num1 and num2 and returns the result. Both num1 and num2 exist inside the IIFE function. This means you've kept the whole setup self-contained within a closure function.

When you call the sum function:

console.log(sum());

and on the next line write:

console.dir(sum);

Check the output. Initially, 2 + 3 gives 5, which is exactly what you see. Since num1 and num2 now exist inside the global scope of the IIFE.

IIFE Closure Output

Full code: example-3.js

// example-3.js
(function () {
    var num1 = 2;
    var num2 = 3;
    function sum() {
        return num1 + num2;
    }
    console.log(sum());
    console.dir(sum);

    num1 = 6;
    num2 = 7;

    console.log(sum());
    console.dir(sum);
})();

You can modify these variables if you want:

num1 = 6;
num2 = 7;

Then if you call again:

console.log(sum());
console.dir(sum);

You'll see two different results. The first call returns 5 because initially 2 + 3 was calculated. After changing num1 and num2, the next call returns 13. So, you can see that a closure keeps hold of the outer variables and makes them accessible inside the function, right?

IIFE Closure with Updated Values Output

Now, at that moment, you checked the function using console.dir. First, expand the dir at the bottom. Here, you see an entry labeled "closure," and inside it, you notice num1 = 6 and num2 = 7. Great, because before writing dir, you had changed the values of num1 and num2, so it's showing the latest values. But if you go back to the previous state and expand the first console.dir, surprisingly, it still shows num1 = 6 and num2 = 7. Both are the same – pretty weird, isn't it?

This is because when you did console.log, the result showed 2 + 3. But in the very next line, the values hadn't actually changed yet. In console.dir, you see that inside the closure, the values remain 6 and 7.

Closure with Updated Values Dir Output

This is exactly what I’ve been emphasizing: a closure doesn't really hold the values themselves. It holds a reference to the variables.

Understanding References

So, what does this mean? It means that there's a pointer stored to the memory location of your variable. Once a reference is stored, the pointer itself stays the same, but the value can change anytime.

When you use console.dir, the browser is showing that reference, which is why it always displays the latest value. The browser works very fast, and the reference has already been updated. When you set num1 and num2 to 6 and 7 inside the closure, the reference gets updated. You're seeing the exact same variable, but you don't see the intermediate values. But when you do console.log, the function uses its corresponding value correctly. That's why not every change in the intermediate scope is clearly visible. Because of reference updates, you always see the latest value, not the direct intermediate state.

Closure Reference Output

So, to reiterate: a closure doesn't store the actual values inside. It stores references to those values.

Keeping this concept in mind is really crucial.

The Difference Between var and let

Full code: example-3.js

// example-3.js
var num1 = 2;
var num2 = 3;
function sum() {
    return num1 + num2;
}

console.dir(sum);

Now, let's look at another aspect of closures. Earlier, you declared two variables in the global scope: num1 and num2. So far, you've been using the var keyword. If you don't put anything inside an IIFE and just stay in the global scope, you won't see any closure in the browser.

No Closure In Global Output

But where do num1 and num2 live? Well, in the global scope. That's why you write console.dir(sum). In the browser, you can see num1 and num2 inside the global object.

Here's the interesting part: what happens if you replace these var keywords with let?

Understanding var and let Scoping

Full code: example-3.js

// example-3.js
let num1 = 2;
let num2 = 3;

function sum() {
    return num1 + num2;
}

console.log(sum());

console.dir(sum);

This is where the difference between var and let comes in. Many people think they're the same, but in JavaScript, var and let are not equal.

Simply put:

  • var is the old JavaScript declaration, and it's function-scoped. A variable declared with var only lives inside the function it's defined in. If it's defined outside any function, it goes to the global scope.

  • let is the new ES6 declaration, and it's block-scoped. A variable declared with let only exists within the block or scope where it was defined and cannot be accessed from outside.

One important difference is hoisting. Variables declared with var are hoisted, meaning JavaScript moves the declaration to the top, but the initialization doesn't happen. So if you use a var before it's declared, you'll get undefined. With let, even though it's hoisted, the temporal dead zone ensures that using it before declaration throws an error.

Observing the Difference

Let's see what happens if you declare the variable with let. Last time, when it was just in the global scope, you could see the variables when you did console.dir. Now, though, you see a new object named script has appeared, and num1 and num2 are no longer in the global scope.

Let Scope Output

Why is that? It's because of the difference between let and var that you talked about earlier. let is block-scoped, while var is function-scoped. If you treat the outer context as a main function, a variable declared with var becomes part of the global scope. But with let, it stays within its block scope and doesn't directly become part of the global object. So let actually lives inside a separate object called script and not in the global scope.

Understanding this is really important, because if you’re following along with this handbook and you’re trying to print variables while using let out of habit, the output won't be like it is with var. This can definitely be confusing. Simply put, let doesn't go into the global object. It exists inside a separate script object.

Using IIFE with let

Full code: example-3.js

// example-3.js
(function () {
    let num1 = 2;
    let num2 = 3;

    function sum() {
        return num1 + num2;
    }

    console.dir(sum);
})();

But what if you wrap the whole thing in an enclosing function again, like before with an IIFE? When you check the output now, everything goes back inside its closure.

Closure with Let in IIFE Output

Ultimately, the concept of closures remains the same: what changes is whether the variable goes into var or let scope.

Now the situation becomes a bit simpler. You have a function, and it's in its end-closing state. According to the definition of a closure, the inner function of this function is using the outer variable num1. So, this inner function definitely needs a closure. That closure comes from exactly this function.

JavaScript creates the closure and packages num1 inside it. The outer global world always exists separately, of course. Also remember, when using console.dir in the browser, the output will look different depending on whether you're dealing with let or var.

Understanding Closures Through a Practical Stopwatch Example

So far, all the examples you've seen were very simple. Now, let's look at a practical example that will help you understand closures better and clear up any confusion.

Full code: example-4.js

// example-4.js
function stopWatch() {
    var startTime = Date.now();

    var getDelay = function () {
        console.log(Date.now() - startTime);
    };
    return getDelay;
}

var timer = stopWatch();

for (let i = 0; i < 100000000; i++) {
    var a = Math.random() * 1000000;
}

timer();

Defining the Stopwatch Function

Let's define a function:

function stopWatch() {}

You've named it stopWatch, and it works just like a real stopwatch. Just like when you start a stopwatch, wait for a while, and then stop it to get the elapsed time, this function will do the same.

First, write:

var startTime = Date.now();

This stores the current time in startTime. Then, inside the function, define:

var getDelay = function () {};

Create a getDelay function, which will log the elapsed time to the console. For that, write:

console.log(Date.now() - startTime);

Here, the elapsed time is calculated by subtracting startTime from the current time. Finally, simply return this getDelay function. The stopWatch function does just one thing: when you call stopWatch, it starts a stopwatch using Date.now() and returns a getDelay function. When you call that getDelay function, it shows the elapsed time from the start time to the current moment.

Using the Stopwatch

Now, call it. Write:

var timer = stopWatch();

Here, you've started the stopWatch. This function executes, which means startTime is set and the getDelay function is defined. Then, stopWatch returns that getDelay function. The stopWatch function itself isn't called directly afterward – you simply called it once, and the outer function returns the getDelay function. Store this returned function in timer.

At this point, the stopWatch is already running because you called it, but you haven't printed anything from getDelay yet. Before calling getDelay, create a fake delay like this:

for (let i = 0; i < 100000000; i++) {}

Use a large for-loop to waste some time. You chose a big number intentionally so it takes a noticeable delay. If you want, you can also perform some expensive operations in the loop, like calculating a random number:

var a = Math.random() * 1000000;

This way, you create a fake delay.

Calling the Timer Function

Now, we come to timer. Timer is actually a function because it was returned by calling stopWatch. This returned getDelay function acts as your actual timer. Let’s call timer() and see what happens. The output doesn't appear instantly – it takes a moment, and then it shows up. So you get a delay.

Stopwatch Output

The question is: how is this still working? The stopWatch function, where you initially called it, has already finished executing. That means everything inside that function should be gone.

So how does timer() still know the value of startTime? Especially after you added such a long delay before calling it? This means the timer function still remembers its parent function – specifically, the startTime variable inside stopWatch. It holds onto that reference.

How? Because of a closure. When getDelay was created, a closure was also created inside it that kept track of the startTime variable. So even after the delay, and even after a long time, it can still use that old value. This shows that JavaScript is really smart. It tracks all variables, references, and closures, and when needed, it can use them again. This is why this behavior is possible: because of closures.

Inspecting the Timer Function

Full code: example-4.js

// example-4.js
function stopWatch() {
    var startTime = Date.now();
    var getDelay = function () {
        console.log(Date.now() - startTime);
    };
    return getDelay;
}

var timer = stopWatch();

for (let i = 0; i < 100000000; i++) {
    var a = Math.random() * 1000000;
}

timer();

console.dir(timer);

If you do:

console.dir(timer);

like before and check the output in the browser, you'll notice it takes some time to appear because of the delay. But even after the delay, it still retains startTime inside the closure.

Timer Closure Output

If you try:

console.log(startTime);

you won't be able to access startTime directly. But since timer is a member function, it can use that startTime you initialized long ago, before the for-loop. It still remembers startTime. No matter how long the delay, it can keep track. Even if there were more lines of code or more expensive operations during the delay, at the end of the day, when you call the timer, the closure ensures that startTime is correctly preserved.

This is one of the more fascinating aspects of JavaScript: it can really remember such information, and this is one of the biggest use cases of closures.

Closures and Garbage Collection

This is one of the most powerful features of closures. Because of closures, no matter how many times you call the timer() function, each call works independently and keeps its own reference. Every time, a new reference is created and held as long as it's needed.

Let's consider a small example – but imagine in a large application, there could be countless closures holding references to many variables. Naturally, the question arises: if so many things are being remembered, will performance suffer?

This is where JavaScript's performance optimization comes in. JavaScript is a smart, garbage-collected language. That means when JavaScript realizes that a reference or variable is no longer needed, it automatically removes it from memory.

In some situations, programmers can manually optimize. For example, if you created a timer holding a reference to a getDelay() function, but you haven't called getDelay() yet, JavaScript doesn't know if it will be used in the future, so it keeps the reference.

Full code: example-4.js

// example-4.js
function stopWatch() {
    var startTime = Date.now();

    var getDelay = function () {
        console.log(Date.now() - startTime);
    };
    return getDelay;
}

var timer = stopWatch();

for (let i = 0; i < 100000000; i++) {
    var a = Math.random() * 1000000;
}

timer();

console.dir(timer);
timer = null;

timer();

If you're certain it won't be used anymore, you can manually clear the reference by writing:

timer = null;

Now, timer() won't work because you set it to null. JavaScript understands that it's no longer needed and garbage collects the reference from memory. If you try this in the browser, you'll see an error: "TypeError: timer is not a function" – because timer is now null.

Timer Null Error Output

Simply put, setting timer = null tells JavaScript, "This variable won't be used anymore, forget it." The Garbage Collector then recognizes that there are no references and quietly removes it from memory, preventing memory waste.

The interesting part is that JavaScript doesn't just run the code – it predicts a lot even before compilation. When it sees timer = null, it already knows, "Okay, the programmer used this timer only this much, and it won't be needed anymore." So as soon as the code finishes running, it intelligently cleans up the memory.

This makes your program automatically optimized. There are no memory leaks, browser load decreases, and JavaScript executes faster. This is a very small example, but it already shows how elegantly you can manage performance in JavaScript.

Closures in Asynchronous Code

So far, all the examples you've seen were using closures in a synchronous way. Now, many people might wonder, "Okay, but how do closures work in asynchronous situations?"

That's a very good question. In real-world coding, most tasks run asynchronously – like with setTimeout, fetch, or event listener functions. The key point is, synchronous code executes line by line, but asynchronous code takes some time to complete. That means you call a function, but its result arrives a little later.

So the question is: if the outer scope has already finished by then, how does the inner function still remember the values of the outer variables?

This is exactly where the true power of closures comes in. A closure keeps the reference to the outer scope as long as the inner function hasn't executed yet. That means whether the code is synchronous or asynchronous, closures work the same way.

Asynchronous Closures

Basic Asynchronous Example with setTimeout

Full code: example-5.js

// example-5.js
function asyncExample() {
    var a = 20;

    setTimeout(function () {
        console.log(a);
    }, 3000);
}

asyncExample();

Now let’s see a small asynchronous example to understand how closures work and why they are just as reliable in asynchronous scenarios.

Define a function:

function asyncExample() {}

Inside this function, write:

var a = 20;

You've defined a variable. Next, use JavaScript's built-in setTimeout function:

setTimeout(function () {});

setTimeout takes two parameters: one is the function to run, and the other is the time in milliseconds, meaning it will call that function after the specified delay.

Now, suppose you put console.log(a) inside that function. Surprisingly, even though a isn't defined inside the timeout function, it can still access the a from asyncExample's outer scope. This is possible because of closures. After 3 seconds, it appears, and you see 20. This is also possible because of closures. The function inside setTimeout doesn't have a defined within itself, yet it can access a from asyncExample's scope.

Asynchronous Closure Output

External Function Reference Example

Full code: example-5.js

// example-5.js
function asyncExample() {
    var a = 20;

    function myFunc() {
        console.log(a);
    }

    setTimeout(myFunc, 3000);
    console.dir(myFunc);
}

asyncExample();

Now, what if you define the setTimeout function outside asyncExample, just for demonstration – like this:

function myFunc() {}

Inside myFunc, write:

console.log(a);

Then pass myFunc into setTimeout and also write:

console.dir(myFunc);

If you check the output of console.dir, you'll see that inside myFunc, the closure contains the variable a=20. This is because a was part of asyncExample's scope, so myFunc can still access it.

Asynchronous Closure with External Function Output

Just like before, this is possible thanks to closures. But here, there's a subtle difference. Earlier, you talked about a reference example, but this reference works a little differently.

Full code: example-5.js

// example-5.js

var a = 20;

function asyncExample() {
    function myFunc() {
        console.log(a);
    }

    setTimeout(myFunc, 3000);
    console.dir(myFunc);
}

asyncExample();

a = 30;

Suppose the variable a=20 was originally inside asyncExample. Now, if you move a to the global scope and write:

var a = 20;

In simple terms, you've defined it outside. Now, the closure won't show it, because it's part of the global scope. a will just exist in the global scope with a value of 20. You call the asyncExample function, which starts the setTimeout timer. Then, on the next line after calling asyncExample, you change the value of a:

a = 30;

Now think: if myFunc is called as the callback for setTimeout and does console.log(a), what value will it show? If you check the output, it will show 30.

Global Variable Asynchronous Closure Output

What does this mean?

When asyncExample is called, the setTimeout starts and myFunc is ready as the callback. Inside myFunc, you have console.log(a). At that moment, a was 20 in its parent scope. But since a is now global and its value has been changed from outside, when the callback executes, it shows 30.

This demonstrates that closures actually hold a reference to the variable. If the variable is global, any external changes are also tracked. So if you expand the global a in the console, you'll see a = 30.

I mentioned earlier that closures keep a reference to the value. So when setTimeout sends the callback to the main thread after 3 seconds, myFunc can still access that reference. Remember, myFunc comes back via setTimeout from another place – it doesn't run directly on the main thread. This is part of asynchronous JavaScript.

The function is called in the main thread after returning from the Web API, but it still retains the reference to a. Since a has been changed globally, when myFunc prints it, it shows the new value 30.

This point is very important. Practicing multiple examples will help you better understand how closures track outer variables in asynchronous situations. This is why you need to be careful when using global variables and var.

This is also the reason var can sometimes cause conflicts, and why the let keyword was introduced. For example, if you define var a globally and later change a somewhere in the program, any asynchronous functions referencing a will use the new value. That's why using var with setTimeout or other asynchronous functions can lead to such issues.

💡An important point is that a closure doesn't keep the entire variable from its parent scope. It only keeps a reference to that variable.

Practical Example: API Requests with Closures

Now, let’s see another practical example of closures. In typical JavaScript applications, you often make AJAX requests to fetch data from an API URL. We’ll see how closures are used in this context. For API requests like this, JavaScript's built-in fetch function can be used, though third-party libraries like axios or jQuery AJAX can also accomplish the same task.

Full code: example-6.js

// example-6.js

function apiFunction(url) {
    fetch(url).then((res) => {
        console.log(res);
    });
}

apiFunction("https://jsonplaceholder.typicode.com/todos/1");

Here, we’ll use fetch for a practical example. First, write a function:

function apiFunction(url) {}

You've named it apiFunction and gave it a parameter called url. This function will send a request to that URL. Then you call the built-in fetch function:

fetch(url);

So what does fetch do with the URL? Basically, fetch returns a promise. You know that to get the output from a promise, you use then. So you write:

.then((res)=>{})

After the response comes back, you use a callback function. Here, you log the response to the console:

console.log(res);

This is how your apiFunction is set up.

Now call the function. You need to pass a URL for the API call. A popular choice is jsonplaceholder, so use its /todos/1 endpoint:

apiFunction("https://jsonplaceholder.typicode.com/todos/1");

Check the output. Notice that it appears after a short delay-this is asynchronous.

API Function Output

To make this clearer, write another line below:

console.log("I am here");

Now the question is: which prints first? Without a doubt, "I am here" prints first, and then the output from apiFunction appears. This clearly demonstrates the flow of asynchronous operations. Since the response comes quickly, it might not have been obvious without this extra line.

API Function with Log Output

What does this mean? The output is coming, right? Here, the connection to closures is that you passed the url parameter from outside when calling apiFunction. This url now exists inside the body of apiFunction. fetch takes it as a parameter, and then the callback function inside then executes much later.

By that time, the call to apiFunction has already finished, but the callback still remembers the variables from its scope. That's why even after the result arrives, you can still access url. To see this, print it:

console.log(url);

Notice that the output is correct. This means that if there were more nested functions inside then, like another then inside a then, all the way down, the innermost function could still access the original url. And this is possible only because of closures.

API Function URL Output

Refactoring with External Function

Full code: example-6.js

// example-6.js

function apiFunction(url) {
    handleResponse = function (res) {
        console.log(res);
        console.log(url);
    };

    fetch(url).then(handleResponse);
    console.dir(handleResponse);
}

apiFunction("https://jsonplaceholder.typicode.com/todos/1");

To demonstrate, let’s rewrite the callback function inside apiFunction a little differently:

function handleResponse(res) {}

This function simply does console.log(url). Now pass handleResponse into the then. Then write:

console.dir(handleResponse);

In the output, you'll see that inside handleResponse, the closure contains url. This is because it was part of apiFunction's scope, so it can access it.

API Function with External Handler Output

Advanced Example - Closures in Loops

Finally, let’s look at another example that often comes up in job interviews. This one is a bit more complex and tricky, and it shows how using closures inside loops can create unpredictable output.

Synchronous Loop Example

Full code: example-7.js

// example-7.js

for (let i = 0; i < 3; i++) {
    function a() {
        console.log(i);
    }
    a();
}

Let’s write a simple for loop:

for (let i = 0; i < 3; i++) {}

This loop will run three times, and inside it we’ll define another function:

function a() {}

Inside this function, you simply do:

console.log(i);

From this, you see that the function a exists within the scope of the for loop, but in reality, it's also accessible in the global scope. Then you call the function a:

a();

The expected output would be 0, 1, 2. First, the value of i prints 0, then 1, then 2 – one after another. Looking at the output, you see 0, 1, 2. This is because you defined i using let.

Synchronous Loop Output

Full code: example-7.js

// example-7.js

for (var i = 0; i < 3; i++) {
    function a() {
        console.log(i);
    }
    a();
}

If you remove let and use var instead, what happens? Even with var, the output will be the same in this simple case because var works outside the block scope. Writing for (var i = 0) or declaring var i separately behaves effectively the same.

// example-7.js

var i;
for (i = 0; i < 3; i++) {
    function a() {
        console.log(i);
    }
    a();
}

So in this case, there's no problem. A closure isn't required because you are running the function in the global scope. Your i prints 0, then 1, then 2, and everything works correctly.

Asynchronous Loop Example

Full code: example-7.js

// example-7.js

for (let i = 0; i < 3; i++) {
    setTimeout(function () {
        console.log(i);
    }, 1000 * i);
}

console.log("After for loop");

Now let's go back and use let for i again. Suppose you want to call the a function from outside the loop. Imagine you wrap the function call in a setTimeout, and in the first parameter you pass the body of a as a callback, while the second parameter is 1000 * i milliseconds.

Using this 1000 * i, you want 0 to print after 1 second, 1 after 2 seconds, and 2 after 3 seconds. When you run this, the output comes exactly as expected: after 1 second, 0 prints; after 2 seconds, 1 prints; and after 3 seconds, 2 prints.

But here's the important point: the for loop itself is synchronous, while the functions inside setTimeout are asynchronous. That means the functions inside setTimeout will execute one by one according to the timer, only after the loop has finished. First after 1 second, then after 2, and then after 3.

You can verify this asynchronous behavior. Suppose at the end of the loop you write:

console.log("After for loop");

Now, if you check the output, "After for loop" prints first, then after 1 second, 0 prints, after 2 seconds, 1 prints, and finally 2 prints. This clearly shows how asynchronous functions execute, right? No confusion there.

Asynchronous Loop Output

The var vs let Problem

Full code: example-7.js

// example-7.js

for (var i = 0; i < 3; i++) {
    setTimeout(function () {
        console.log(i);
    }, 1000 * i);
}
console.log("After for loop");

Now, let's see what happens if you replace let i with var i. The interesting part is, if you use "var i" instead of "let i", the behavior changes. All three outputs end up being 3. You don't get 0, 1, 2 like before. That's exactly the tricky part of this question.

Var Loop Problem Output

This question often comes up in job interviews because it's a bit advanced, but if you understand closures and the difference between let and var scopes, it's not complicated at all. You can analyze this by going back to let. Remove var and write:

let i = 0;

Now the expected output is 0, 1, 2. let is block-scoped, meaning this i exists only inside the loop and has no effect outside.

Let Loop Output

During the first iteration, i is 0, and the setTimeout function is defined. This function will be called after the loop finishes, so a closure is used to remember the value of i. The callback needs a closure to reference i correctly. Since let doesn't leak outside the loop, each iteration creates a new i. For example, when i becomes 1, it's a completely separate i from the previous iteration.

Full code: example-7.js

// example-7.js

var i;

for (i = 0; i < 3; i++) {
    setTimeout(function () {
        console.log(i);
    }, 1000 * i);
}
console.log(i);
console.log("After for loop");

So, when this function runs the second time, it references this new i. But with var, the situation is different. var is function-scoped, so the same variable exists outside the loop. If you write:

var i;

and then use the loop:

for (i = 0; i < 3; i++) {}

there is only one i. Changing i inside the loop modifies the same i – no new i is created. So when the setTimeout callbacks execute, they all reference that same i. From previous examples, you know setTimeout callbacks run after the loop finishes. Now, after the loop ends, what's the value of i? Since you used var, i has become 3.

Check it with:

console.log(i);

In the console, you'll see 3 prints first. That means that when the callbacks execute, they all reference the same i, which is already 3.

Var Loop Problem with Log Output

So every console.log in the callbacks prints i = 3, which explains the output perfectly.

Using console.dir with Loop Closures

Full code: example-7.js

// example-7.js

// var i;

for (let i = 0; i < 3; i++) {
    function myFunc() {
        console.log(i);
    }

    setTimeout(myFunc, 1000 * i);

    console.dir(myFunc);
}

console.log("After for loop");

To understand this even better, you can use "console.dir" like before.

Let's see how. First, you'll stick with the let case. So in the for loop you write:

let i = 0;

You comment out the global "var i;" since let is block-scoped. Now let's see how the closure works. The closure is created inside the setTimeout callback function, and you want to inspect this callback function.

For that, you define:

function myFunc() {}

and pass this myFunc inside setTimeout. Then, to inspect it, write:

console.dir(myFunc);

If you run this, the browser shows the same output. That means the dir of myFunc appears three times, but in Chrome's console, it only prints once. Chrome wraps similar objects together, so even though the internal properties are different, it doesn't display them separately. To see each property individually, take the next step.

Let Loop with Dir Output

Below the dir, write:

console.log("---");

This acts as a separator. Now, when the browser prints myFunc's dir, it also prints the separator, making it clear that each instance is separate.

At the same time, outside the for loop, add:

console.log("After for loop");

Now, if you check the output, the browser prints 'After for loop' first, then 0, 1, 2. When you defined it, the console logs show myFunc and the dashes.

Let Loop with Dir and Separator Output

Notice, when i is 0, the closure holds i = 0. When i = 1, the closure holds i = 1. When i = 2, the closure holds i = 2. So, all three values exist as references until the end, which is why you get three separate outputs.

Let Loop Closure Values Output

The var Loop Problem

Full code: example-7.js

// example-7.js

for (var i = 0; i < 3; i++) {
    function myFunc() {
        console.log(i);
    }

    setTimeout(myFunc, 1000 * i);

    console.dir(myFunc);

    console.log("---");
}

console.log("After for loop");

console.log(i);

But what happens if you replace "let i" with "var i"? After printing 'After for loop', all three outputs show 3. How? When i is 0, there's no closure because var moves this variable to the global scope. Unlike the previous example, no closure is needed here. Var exists in the global scope, and i changes within that same global variable.

Var Loop with Dir Output

So, if you expand the first myFunc in the console and look for i in the global scope, you'll see i = 3. Why? Because the for loop finishes first, and at the end, i becomes 3. At the moment of 'After for loop', i is 3. If you do "console.log(i)" there, the browser prints 3. This means, when the reference values are called, they still use the reference to that i. Even if i changes later in the program, since the calls happen afterward, the reference values get the updated i.

That's why the first call shows 3, the second call shows 3, and the third call also shows 3. If you expand them all, you'll see i = 3 everywhere. This happens because no closure is used here; it's referencing the original i in the global scope, which keeps updating.

Var Loop Closure Values Output

The difference in scope between let and var is why the output changes completely.

Fixing the var Loop Problem with IIFE

To fix this var issue, you can create an IIFE inside the for loop. This IIFE will take one parameter: in this case, the value of your loop variable "i."

Full code: example-7.js

// example-7.js

for (var i = 0; i < 3; i++) {
    (function (i) {
        function myFunc() {
            console.log(i);
        }

        setTimeout(myFunc, 1000 * i);

        console.dir(myFunc);

        console.log("---");
    })(i);
}

console.log("After for loop");

You write the code. Inside the IIFE, you're passing a parameter named "i." Of course, you can name it anything you want – you already know that. But for now, just keep it as "i." Then, when you call the IIFE, pass the loop's "i" value into it. Nice, right?

Let's see what the output looks like. This time, you get 0, 1, and 2 correctly. So, why is it fixed now? Because "i" is now inside its own scope within the IIFE. Whenever you pass "i" to myFunc, a separate copy of that "i" is created as a parameter inside myFunc, and that copy is what gets used inside the function.

IIFE Loop with Dir Output

Everything's clear now, right? If you expand the dirs at the end, you'll see: the last one has "i = 2" in its closure, the second one has "i = 1," and the first one has "i = 0." Perfectly clear, isn't it?

IIFE Loop Closure Values Output

Summary and Key Takeaways

If you have a solid grasp of the overall concepts discussed here, and if you practice all these examples repeatedly, your understanding of closures will become much stronger.

Of course, there are more complex examples of closures, but the basics we've covered today are the most important. Once you understand them step by step, you'll be able to create many use cases yourself and debugging will no longer be difficult. Because now, with just a glance at console.dir() or by playing with the code a bit, you can see how closures actually work.

Not having a good understanding of closures can make you get stuck in many parts of JavaScript, especially when working with asynchronous code.

To summarize:

If you're asked in a job interview, "What is a Closure?" you can answer simply:

A closure is a mechanism where a function remembers variables outside its own scope and can access them whenever needed.

In other words, values that aren't inside the function itself, but the function takes a reference from its parent or outer scope. This is what we call a Closure.

Closure = Function + Remembered Values

This is why closures are so important in job interviews. They show how deeply a programmer understands JavaScript. A programmer who understands closures can clearly grasp JavaScript's internal behavior, memory handling, and asynchronous flow.

The Importance of Closures

JavaScript was originally created just for small interactive tasks in the browser, but now you can build large-scale applications, even backend systems, with it. The reason behind this is powerful concepts in JavaScript like Closures, Prototypes, and more.

Many people say, "I know var, let, const, so tell me about closures." But as you've seen, var, let, and const aren't that simple either. This is where the understanding of closures begins.

Final Words

We covered a lot in this handbook! If reading this all at once feels overwhelming, you can break it into parts and read it step by step. I’ve tried to explain the whole topic very simply, piece by piece. If there are any areas that could be clearer, I appreciate your feedback. But once you’ve really understood and digested this info, you shouldn’t be intimidated by the word "Closure" ever again.

You can find all the source code from this tutorial in this GitHub repository. If it helped you in any way, consider giving it a star to show your support!

If you found the information here valuable, feel free to share it with others who might benefit from it. I’d really appreciate your thoughts – mention me on X @sumit_analyzen or on Facebook @sumit.analyzen, watch my coding tutorials, or simply connect with me on LinkedIn. You can also checkout my official website sumitsaha.me for more details about me.

]]> <![CDATA[ How to Use Closures in Go ]]> https://www.freecodecamp.org/news/how-to-use-closures-in-go/ 68ffd791ca908949cd4f2afc Mon, 27 Oct 2025 20:35:29 +0000 If you've written code in JavaScript, Python, or Rust, you've probably heard the word closure before. The concept has subtle differences in each language, but the core idea is the same: a closure is a function that captures variables from its surrounding scope. This allows the function to "remember" the environment in which it was created, even when it's executed outside that environment, which has powerful implications for how we write and structure our code.

In this article, we'll explore how closures work in Go, a statically typed language known for its simplicity and efficiency. We'll look at how to create closures, how they capture variables, and some practical use cases.

What We'll Cover

Prerequisites

To follow along with this article, you should have a basic understanding of Go programming, including functions and variable scope. If you're new to Go, consider checking out the official Go tour to get up to speed.

What Closures Really Are in Go

At its simplest, a closure in Go is a function that references variables defined outside of it. That may sound abstract, so let's start with an example you can run right away:

package main

import "fmt"

func counter() func() int {
    n := 0
    return func() int {
        n++
        return n
    }
}

func main() {
    next := counter()
    fmt.Println(next()) // 1
    fmt.Println(next()) // 2
    fmt.Println(next()) // 3
}

When you call counter(), it returns another function, but that function keeps access to the variable n that lived inside counter.

Even though counter() has already finished running, n hasn't disappeared. Each time you call next(), it updates the same n that was created during the original counter() call.

This is the defining property of a closure:

A closure "closes over" its environment, keeping the variables it needs alive for as long as the closure itself exists.

How Go Makes This Work

Normally, local variables in Go live on the stack, which is cleared when a function returns.

But if a nested function needs to keep using one of those variables, Go's compiler performs what's called escape analysis: it sees that the variable will outlive the function call, so it moves that variable to the heap, where it can stay alive as long as something references it - in this case, the closure.

You can actually ask the compiler to show you this process:

go build -gcflags="-m" main.go

You might see output like:

./main.go:6:6: moved to heap: n

That tells you the variable n "escaped" the stack so the closure could use it safely later.

Multiple Independent Closures

Each call to a function that returns a closure creates a new, independent environment:

a := counter()
b := counter()
fmt.Println(a()) // 1
fmt.Println(a()) // 2
fmt.Println(b()) // 1

Here, a and b are two separate closures, each with its own n. Calling a() increments its own n, while calling b() starts from its own separate n.

The Classic Loop Trap

One of the most common surprises for Go developers comes when closures are used inside a loop. Even experienced programmers often fall into this trap.

Consider this example:

package main

import "fmt"

func main() {
    funcs := make([]func(), 0)
    for i := 0; i < 3; i++ {
        funcs = append(funcs, func() {
            fmt.Println(i)
        })
    }
    for _, f := range funcs {
        f()
    }
}

You might expect this to print 0, 1, and 2, but it actually prints

3
3
3

Why Does this Happen?

Inside the loop, each function literal captures the variable i itself, not its value at that moment.

The loop reuses the same i variable for all iterations. By the time the loop finishes, i equals 3, and all the closures see this same i when they run later.

How to Fix It

There are two common idiomatic fixes:

  1. Shadow the loop variable:
for i := 0; i < 3; i++ {
    i := i // new variable shadows the loop variable
    funcs = append(funcs, func() {
        fmt.Println(i)
    })
}
  1. Pass the variable as a parameter to an inner function:
for i := 0; i < 3; i++ {
    funcs = append(funcs, func(x int) func() {
        return func() { fmt.Println(x) }
    }(i))
}

Both approaches create a new variable for each iteration, so each closure captures its own independent value.

How to Create Closures in Go

There are a few different ways to create closures in Go. Let's explore some common patterns.

Returning Closures From Functions

The most common pattern is having a function return a closure that keeps its own state:

func makeCounter() func() int {
    n := 0
    return func() int {
        n++
        return n
    }
}

c1 := makeCounter()
fmt.Println(c1()) // 1
fmt.Println(c1()) // 2

Each call to makeCounter creates a new closure with its own n, as we saw earlier.

Named Inner Functions

You can also give a name to a function literal for readability or debugging:

func makeCounter() func() int {
    n := 0
    next := func incr() int {
        n++
        return n
    }
    return next
}

This works the same way but gives the inner function a name (incr), which can be helpful in stack traces. Other than that, it behaves just like an anonymous function.

Inline Closures in Loops or Goroutines

Closures are often defined inline, especially for loops or goroutines:

for i := 0; i < 3; i++ {
    go func(x int) {
        fmt.Println(x)
    }(i)
}

Here, we pass i as a parameter to the closure, ensuring each goroutine gets its own copy of the value, avoiding the loop variable trap.

Closures With Parameters

Closures can accept their own arguments:

func adder(base int) func(int) int {
    return func(x int) int {
        return base + x
    }
}

add5 := adder(5)
fmt.Println(add5(10)) // 15

Here, adder returns a closure that adds a fixed base value to whatever argument it receives.

Capturing Multiple Variables

Closures can capture multiple outer variables:

func multiplier(factor int) func(int) int {
    offset := 2
    return func(x int) int {
        return x*factor + offset
    }
}

m := multiplier(3)
fmt.Println(m(4)) // 14

In this example, the closure captures both factor and offset from its surrounding scope - factor is a parameter, while offset is a local variable.

Closures in Structs

Closures can also be stored in structs, just like any other function value. This is a useful pattern when you want objects with dynamic or stateful behavior.

type Counter struct {
    Next func() int
}

func NewCounter() Counter {
    n := 0
    return Counter{
        Next: func() int {
            n++
            return n
        },
    }
}

func main() {
    c := NewCounter()
    fmt.Println(c.Next()) // 1
    fmt.Println(c.Next()) // 2
}

Here, the Next field holds a closure that captures the variable n. Each instance of Counter has its own independent state, without needing a separate type or mutex.

This pattern shows how closures can act as lightweight objects: bundling behavior and state together.

Note on Method Receivers

Closures in Go don't implicitly capture the method receiver like some languages do. If you want a closure to use the receiver inside a method, you typically assign it to a local variable:

type Counter struct {
    n int
}

func (c *Counter) MakeIncrementer() func() int {
    r := c // capture receiver explicitly
    return func() int {
        r.n++
        return r.n
    }
}

This ensures the closure references the intended receiver rather than introducing unexpected behavior.

Unlike JavaScript or Python, Go closures capture lexical variables, not the implicit this or self.

Key Takeaways

  • Closures can be returned from functions, named, inlined, or even stored in structs.

  • They capture outer variables, not copies of their values.

  • Used this way, closures can replace small types or interfaces for lightweight encapsulation.

Closures and Concurrency

Closures are powerful in Go, but when you combine them with concurrency, their captured variables can act in unexpected ways if you're not careful.

Independent State Across Goroutines

Each closure keeps its own captured variables alive, even when used in concurrent goroutines:

func makeWorker(start int) func() int {
    counter := start
    return func() int {
        counter++
        return counter
    }
}

func main() {
    worker1 := makeWorker(0)
    worker2 := makeWorker(100)

    go func() { fmt.Println(worker1()) }() // prints 1
    go func() { fmt.Println(worker2()) }() // prints 101
}

Here, worker1 and worker2 have independent counter variables, so they don't interfere with each other. Each closure maintains independent state, even in separate goroutines.

Capturing Shared Variables Safely

When multiple closures share a variable, you must coordinate access. For example:

counter := 0
ch := make(chan int)

for i := 0; i < 3; i++ {
    go func() {
        // increments a shared variable
        ch <- 1
    }()
}

// aggregate safely
for i := 0; i < 3; i++ {
    counter += <-ch
}
fmt.Println(counter) // 3

The closure captures the outer variable ch (a channel), which is safe because channels serialize access. Using a buffered channel here wouldn't change the behavior of the closure: it still captures its own n and sends the values to the channel independently.

Closures themselves don't synchronize shared state, you still need channels or mutexes.

Practical Patterns with Closures

Closures in Go aren't just a language curiosity, they're a powerful tool for writing stateful, reusable, and flexible code. Here are a few practical patterns that go beyond the basics.

Memoization / Caching

Closures can capture an internal map or cache to store results of expensive computations:

func memoize(f func(int) int) func(int) int {
    cache := map[int]int{}
    return func(x int) int {
        if val, ok := cache[x]; ok {
            return val
        }
        result := f(x)
        cache[x] = result
        return result
    }
}

func main() {
    fib := memoize(func(n int) int {
        if n <= 1 {
            return n
        }
        return fib(n-1) + fib(n-2)
    })
    fmt.Println(fib(10)) // 55
}

Here, the memoize function returns a closure that caches results of the Fibonacci function, avoiding redundant calculations.

Event Handlers / Callbacks

Closures are perfect for defining event handlers or callbacks that need to maintain state:

type Button struct {
    onClick func()
}

func (b *Button) Click() {
    if b.onClick != nil {
        b.onClick()
    }
}

func main() {
    count := 0
    button := Button{
        onClick: func() {
            count++
            fmt.Println("Button clicked", count, "times")
        },
    }

    button.Click() // Button clicked 1 times
    button.Click() // Button clicked 2 times
}

In this example, the closure captures the count variable, allowing the button to keep track of how many times it has been clicked.

Encapsulated Pipelines / Producers

Closures can wrap stateful logic for channels and pipelines:

func producer(start int) func(chan int) {
    n := start
    return func(ch chan int) {
        for i := 0; i < 3; i++ {
            ch <- n
            n++
        }
    }
}

func main() {
    ch := make(chan int, 3)
    go producer(5)(ch)
    for i := 0; i < 3; i++ {
        fmt.Println(<-ch) // 5, 6, 7
    }
}

Here, the producer function returns a closure that sends a sequence of numbers to a channel, maintaining its own state with n.

Deferred Execution with Captured State

Using a closure with defer lets you capture variables at the moment the defer statement is executed, which is especially useful in loops or resource cleanup:

func main() {
    for i := 0; i < 3; i++ {
        defer func(x int) {
            fmt.Println(x)
        }(i) // capture current i
    }
}

Output:

2
1
0

Here, each deferred closure captures the value of i at the time of the defer statement, so they print in reverse order when the function exits.

How to Implement Interfaces Dynamically

Closures can also be used to implement interfaces without defining a full struct type. For example, a simple function can satisfy a single-method interface:

type Greeter interface {
    Greet() string
}

func MakeGreeter(name string) Greeter {
    return struct{ Greeter }{
        Greeter: func() string { return "Hello, " + name },
    }
}

func main() {
    g := MakeGreeter("Alice")
    fmt.Println(g.Greet()) // Hello, Alice
}

Here, the closure captures name, allowing the returned object to implement the Greet method dynamically.

Key Takeaways

  • Closures allow memoization and caching without extra structs.

  • Storing closures in structs provides customizable behavior for objects.

  • Closures can encapsulate stateful concurrent pipelines, keeping logic localized and safe.

  • Closures with defer capture variables at the time of deferment, useful for cleanup or logging.

  • They enable dynamic interface implementations without boilerplate types.

How Closures Affect Memory and Performance

Closures are powerful, but capturing variables from outer scopes has memory and performance implications.

Variables May Live Longer Than Expected

Because closures keep references to captured variables (and move them to the heap if necessary, as we saw earlier), these variables live as long as the closure itself, which can increase memory usage:

func main() {
    bigData := make([]byte, 10_000_000) // 10MB
    f := func() int { return len(bigData) }
    _ = f
}

In this example, bigData remains in memory as long as the closure f exists, even if bigData is no longer needed elsewhere.

Many Closures Can Add Overhead

Each closure carries a small environment for its captured variables. Creating thousands of closures is usually fine, but in high-performance or memory-sensitive code, this can add measurable overhead.

  • Captured variables may be heap-allocated.

  • Each closure has a small hidden struct for its environment.

Alternatives include structs or plain functions when you need maximum efficiency.

How to Test and Debug Closures

Closures can sometimes behave in unexpected ways when capturing variables or working with concurrency. Here are some tips to test and debug them effectively.

Isolate the Closure

Test the closure independently of its outer function to verify its behavior:

func TestCounter(t *testing.T) {
    counter := makeCounter()
    if counter() != 1 {
        t.Error("expected 1")
    }
    if counter() != 2 {
        t.Error("expected 2")
    }
}

This ensures the closure maintains state correctly.

Check Captured Variables

Remember: closures capture variables by reference, not value. Be mindful of loop variables or shared state:

for i := 0; i < 3; i++ {
    i := i // shadow loop variable
    t.Run(fmt.Sprintf("i=%d", i), func(t *testing.T) {
        if i != i { // simplified check
            t.Fail()
        }
    })
}

This helps avoid the loop trap in tests.

Use Logging or Debug Prints

Printing internal closure state is often the fastest way to debug subtle behavior:

adder := func(base int) func(int) int {
    return func(x int) int {
        fmt.Printf("base=%d, x=%d\n", base, x)
        return base + x
    }
}
result := adder(5)(10) // logs: base=5, x=10

Test Concurrency Carefully

When closures are used in goroutines, race conditions can creep in. Use the Go race detector:

go test -race ./...

This flags any shared variable access that isn’t properly synchronized.

Key Takeaways

  • Test closures independently to ensure captured state behaves as expected.

  • Be cautious with loop variables and shared state.

  • Use logging and the race detector to debug concurrency issues.

Best Practices and Takeaways for Using Closures in Go

Closures are a versatile feature in Go, but like any tool, they work best when used thoughtfully. Here are some practical guidelines:

  • Encapsulate state cleanly: Use closures to maintain private state without introducing extra structs or types. Counters, memoization caches, and small factories are common patterns.

  • Be careful in loops: Always capture loop variables correctly to avoid the classic loop trap. Shadowing the variable or passing it as a parameter to the closure are idiomatic solutions.

  • Handle concurrency explicitly: Closures can safely maintain independent state in goroutines, but they do not synchronize shared state automatically. When multiple closures share variables, coordinate access with channels or mutexes.

  • Mind memory usage: Captured variables may escape to the heap, so long-lived closures can retain more memory than expected. Avoid capturing large objects unless necessary.

  • Leverage closures in structs: Storing closures in struct fields allows objects to have dynamic or customizable behavior without extra boilerplate, making your code more flexible.

Conclusion

Closures in Go allow functions to carry state, encapsulate behavior, and interact safely with concurrency patterns, all while keeping your code clean and expressive. By understanding how closures capture variables, how they behave in loops and goroutines, and their memory implications, you can use them confidently to write more idiomatic and maintainable Go code.

]]> <![CDATA[ How Do Closures Work in JavaScript? Explained with Code Examples ]]> https://www.freecodecamp.org/news/understand-javascript-closures/ 66c37506d0cda7b58da26c34 Tue, 07 May 2024 07:13:36 +0000 Sally and Joe are two love birds. They shared everything with each other and soon enough it was almost impossible to think that anything could come between them. One day, they had a quarrel which built up to a break up.

It was hard for Joe and he wanted "closure". Although Sally already moved on, Joe found closure by taking time to think through the whole experience, recalling "shared memories" and properly introspecting. Even though the relationship had ended, Joe still had something that reminded him of Sally and he was cool with that.

The story ends.

If this is your first time hearing of the term "closure", I'll do you the honor of telling you what it means.

Closure is simply the act of bringing something to an end. Closure in a relationship refers to the sense of peace and understanding you get after the relationship comes to an end. It's that feeling of "letting go" and being able to move on.

For some people, getting closure involves holding on to a "shared memory" with the other party, or something (perhaps an item) that reminds them of the other.

Now that you are familiar with the term closure as it relates to humans, let's try to understand it in terms of the relationship between functions in JavaScript.

In JavaScript, a closure is said to be created when a function retains access to resource(s) declared in it's parent scope even after the parent function has been removed from the call stack.

Note: In JavaScript, when a function is said have been popped-off/removed from the stack, it means that the function has completed its life-span (is done executing), and all of its resources have been removed from memory and are no longer accessible.

Think of the call stack like the world, while parent and child are two entities in the world.

In this case, parent is the function that has completed execution and logically, everything about it should be out of reach. But because of the concept of closure, even when the relationship between the parent and child functions has ended – that is, when the parent gets popped-off the stack (removed from the world) – the child function still remembers everything they shared together.

Note: Everything they shared together as used above simply means the variables declared in the parent function which are used by the child function.

function parent () {
    let a = "Az";

    return function child () {
        console.log(a);
    }
}

In the code snippet above, the variable a is what the parent and child functions shares together.

So even when parent gets removed from the call stack, child still remembers the value of a for as long as it lives.

If you stop reading at this point, you already know what closure is conceptually. But if you want to fully understand it and never forget, we'll have to take a deep dive into the workings of JavaScript.

Deep Dive into the Concept of Closure.

To really understand closures in JavaScript, you have to be familiar with the following concepts:

  1. The concept of functions being first-class citizens in JavaScript. This means that:

  2. Functions can be assigned to variables as values

const getName = function () {
    return 'Allice'   
};

Now you can simply call the function getName just like you would call any other function using the parenthesis like this getName()

Think of functions as callable objects. This means, just like we can assign objects to variables and pass them around, you can do same with functions. The difference between them is that you can call a function when you need the code in it to execute.

  • Functions can be passed into other functions as arguments
setTimeout(getName, 5000)

As you can see in the code snippet above, during the invocation of the setTimeout function, we passed the getName function into it as an argument. Again, this is because functions are simply objects that are callable.

Take note that when we pass the getName function into the setTimeout function, we are not calling/invoking it. We are simply passing the function as a value.

If we called the function, we'd be passing its return value instead and that's a significant difference there.

I'd also like to bring to your notice that mentioning the name of a function is simply referencing that function. Behind the scene, the function name gets replaced by the function itself.

That is, this code setTimeout(getName, 5000) is equivalent to the code below;

setTimeout(function () {
    return 'Allice'   
}, 5000)

The function name gets replaced with the function itself during execution just like a regular variable name gets replaced by its value during execution.

  • Functions can be returned from other functions.
function multiplyBy (numberToMultiplyBy) {
    return function (numberToMultiply) {
        return numberToMultiply * numberToMultiplyBy
    }
}

Taking a close look at the code snippet above, you'll notice that we have a function called multiplyBy which expects an argument during invocation and returns a new function.

The interesting thing to notice here is that when we call the returned function, it expects an argument too, but this time, it remembers the argument passed into the original multiplyBy function ( numberToMultiplyBy ), then multiplies the value passed into itself ( numberToMultiply ) with the value passed into its parent function, and returns the result.

Carefully observe the code below which makes use of the higher-order function multiplyBy:

const multiplyByTwo = multiplyBy(2)
const result = multiplyByTwo(8)

console.log(result) // 16
  1. The concept of Higher-order functions: This is the second concept you need to be aware of to understand closure.

A higher order function is a function which:

  • Accepts a function as an argument. For example: setTimeout, Promise, and so on.
  • Returns a function. For example: multiplyBy function declared above.
  • Or fulfils the first and second items above.

Now that you understand that functions are first-class citizens and you've seen implementations of a higher-order function, we can proceed to talk about closures.

Recall that a closure occurs when a child function holds reference to/remembers a value or resource which belonged to its parent function even after the parent function has been removed from the call stack.

Consider this code:

function sally () {
    let age = 64;

    return function joe () {
        const data = {
            name: "Joe",
            parentName: "Sally",
            parentAge: age
        }
        return data
    }
}

In the code snippet above, we can observe that:

  • sally is the parent function and it declares a scope
  • age is a variable declared within the sally scope
  • joe is a function which lives in the sally scope and is returned by the sally function. You should also note that:
  • joe defines its own scope which is a child scope of the sally scope
  • within the joe scope, we make reference to the variable age which belongs to sally scope (this is where closure happens because joe is referring or holding on to a resource/variable which belongs to sally).

Because joe holds a reference to the variable age which belongs to sally, even when sally has been popped-off the call stack and its scope discarded, joe will retain access to the age variable because of the concept of closure.

So in the code below:

const joe = sally() // sally is invoked and returns the joe function
const joeyData = joe() // joe function is invoked and returns an object

console.log(joeyData) // we log the object returned.

You can observe that even though sally is called and popped-off the stack, when you invoke joe and log the return value of joe to the console, it still remembers the age of sally during the execution (which we can access in the returned object like so joeyData.parentAge).

Summary

When a child function refers to variables used in its parent scope, closure occurs.
Closure is like a memory box which stores all the items of the parent scope that are referred to from the child scope.

A look at the slides below should cement the knowledge you've gained so far and hopefully everything will fall in place.

Closures unlocked? Level up your JavaScript skills with more full-stack development tutorials on my YouTube channel. Subscribe now for my next playlist on fundamental JavaScript concepts!

Thanks for reading! Happy coding!

]]> <![CDATA[ Closure in JavaScript – Explained with Examples ]]> https://www.freecodecamp.org/news/javascript-closures-explained-with-example/ 66bb554d4c9d249e52882f2b Wed, 13 Apr 2022 18:57:03 +0000 In this article, we are going to talk about closures in JavaScript. I'll walk you through the definition of a closure, a simple day-to-day fetch utility closure example, and some of the advantages and disadvantages of using closures.

Table of Contents

Without further ado, let's get started.

Prerequisites

You should have a good understanding of the following topics to understand this article:

What are closures?

Closures are functions that have access to the variables that are present in their scope chain even if the outer function ceases to exist.

To understand this in more detail, let's understand what a scope chain is. Scope chain refers to the fact that parent scope does not have access to the variables inside its children's scope, but the children's scope does have access to the variables present in its parent scopes.

Let's make this clearer by taking a look at an example below:

let buttonProps = (borderRadius) => {
    const createVariantButtonProps = (variant, color) => {
        const newProps = {
            borderRadius,
            variant,
            color
        };
        return newProps;
    }
    return createVariantButtonProps;
}

As you can see, we have a function called buttonProps. This function accepts borderRadius as an argument. Let's consider the buttonProps function as our parent function.

We have another function that has been defined inside the parent function, that is createVariantButtonProps. This function will accept variant and color as an argument and return an object that constitutes a variable borderRadius that is present outside its scope.

But a question arises as to how the inner function resolves the variables that are present in the parent scope.

Well, this is possible via lexical scoping. Using lexical scoping, the JS parser knows how to resolve variables present in its current scope or in fact knows how to resolve variables present in the nested functions.

So based on the above explanation, createVariantButtonProps will have access to the variables present in its outer function buttonProps.

In the above example, the inner function createVariantButtonProps is a closure. To understand closures in detail we will first go through the characteristics of closures which are as follows:

  • Even if the outer function ceases to exist, a closure still has access to its parent variables.
  • Closures do not have access to their outer function’s args parameter.

Let's get into more detail on each of these points.

Even if the outer function ceases to exist, it still has access to its parent variables.

This is the basic functionality of any closure. This is their main life motto aka their working principle.

To see this in action we will now execute the above buttonProps function.

let primaryButton = buttonProps("1rem");

Calling the buttonProps function will return us another function that is our closure.

Now let's execute this closure:

const primaryButtonProps = primaryButton("primary", "red");

Once the closure is executed, it returns the following object:

{
   "borderRadius":"1rem",
   "variant":"primary",
   "color":"red"
}

Here again a question arises: How does the primaryButton function have access to the variable borderRadius that was not present inside it?

If we go through the definition of closures, and scope chaining that we discussed earlier, it perfectly fits into that instance.

Let's dig deeper into why closures still have access to the variables that are defined outside their scope, even if the outer function ceases to exists – for example, borderRadius?

The answer is simple: closures do not store static values. Instead, they store references to the variables present inside the scope chain. In this way, even if the outer function dies, the inner function, that is a closure, still has access to its parent variables.

Use case of closure: Creating a fetch utility with closures

Now that we've learned what closures are, we will create a nice general purpose utility function. It will handle different request methods such as GET and POST with REST APIs.

For this use case,

  • We will be using JSON placeholder APIs. This provides us with some fake data which we can edit using REST APIs.
  • We will be using JavaScript's fetch API.

Let's first discuss why we even need to design such a utility. There are couple of reasons:

  • For every fetch call, we don’t want to define the base URL (or other common parameters) all the time. So we will create a mechanism that will store the base URL/parameters as a state.
  • To remove redundant code.
  • To provide modularity in the codebase.

Let's dive into the details of this utility. Our fetch utility will look like below:

const fetchUtility = (baseURL, headers) => {
  const createFetchInstance = (route, requestMethod, data) => {
    const tempReq = new Request(`${baseURL}${route}`, {
      method: requestMethod,
      headers,
      data: data || null
    });
    return [fetch, tempReq];
  };

  return createFetchInstance;
};
  • fetchUtility accepts two parameters that are baseURL and headers. These will be used later in the closure to construct the base URL along with the headers.
  • Then we have createFetchInstance, which accepts route requestMethod and data as parameters.
  • Next, this function creates a new request object that will construct our URL using the code: ${baseURL}${route}. We also pass in an object which consists of the request method type, headers, and data if available.
  • Then we return the instance of a fetch API along with the request object.
  • Lastly, we return the createFetchInstance function.

Now let's see this function in action. Call our fetchUtility function to initialize the baseURL:

const fetchInstance = fetchUtility("https://jsonplaceholder.typicode.com");
  • If we observe, the fetchInstance now has the value of the closure of the function fetchUtility.
  • Next, we pass the route and the type of the request to the closure fetchInstance:
const [getFunc, getReq] = fetchInstance("/todos/1", "GET");

As you can see this returns us an array of fetch API instance and the request body that we configured.

Finally, we can make use of the getFunc fetch API to call the request getReq like below:

getFunc(getReq)
  .then((resp) => resp.json())
  .then((data) => console.log(data));

We can also create a POST request similar to the above GET request. We just need to call the fetchInstance again as below:

const [postFunc, postReq] = fetchInstance(
  "/posts",
  "POST",
  JSON.stringify({
    title: "foo",
    body: "bar",
    userId: 1
  })
);

And to execute this post request we can do the similar operation that we did for the GET request:

postFunc(postReq)
  .then((resp) => resp.json())
  .then((data) => console.log(data));

If we closely look at the above example, we can see that the inner function createFetchInstance has access to the variables present in its scope chain. With the help of lexical scoping, during its definition of createFetchInstance it resolves the variable names.

In this way the closure references the variables baseURL and headers during its definition even after the outer function fetchUtility has ceased to exist.

If we think of closures from a different perspective, then closures help us to maintain a state like baseURL and headers that we can use across function calls.

Advantages of closures

Here are some advantages of closures:

  • They allow you to attach variables to an execution context.
  • Variables in closures can help you maintain a state that you can use later.
  • They provide data encapsulation.
  • They help remove redundant code.
  • They help maintain modular code.

Disadvantages of closures

There are two main disadvantages of overusing closures:

  • The variables declared inside a closure are not garbage collected.
  • Too many closures can slow down your application. This is actually caused by duplication of code in the memory.

Summary

So in this way closures can be really useful if you want to deal with or implement certain design patterns. They also help you write neat and modular code.

If you liked the idea of closures, then I would recommend reading further on the following topics:

Thank you for reading!

Follow me on Twitter, GitHub, and LinkedIn.

]]> <![CDATA[ Scope and Closures in JavaScript – Explained with Examples ]]> console.log(word); } const sayHello = sayWord("hello"); sayHello(); // "hello" This code is interesting for a... ]]> https://www.freecodecamp.org/news/scope-and-closures-in-javascript/ 66d461714bc8f441cb6df82d Tue, 01 Feb 2022 23:52:27 +0000 By Zach Snoek

You may have come across or written code similar to this when writing JavaScript:

function sayWord(word) {
    return () => console.log(word);
}

const sayHello = sayWord("hello");

sayHello(); // "hello"

This code is interesting for a couple of reasons. First, we can access word in the function returned from sayWord. Second, we have access to word’s value when we call sayHello – even though we call sayHello where we do not otherwise have access to word.

In this article, we’ll learn about scope and closures, which enable this behavior.

Introducing Scope in JavaScript

Scope is the first piece that will help us understand the previous example. A variable’s scope is the part of a program where it is available for use.

JavaScript variables are lexically scoped, meaning that we can determine a variable’s scope from where it is declared in the source code. (This is not entirely true: var variables are not lexically scoped, but we will discuss that shortly.)

Take the following example:

if (true) {
    const foo = "foo";
    console.log(foo); // "foo"
}

The if statement introduces a block scope by using a block statement. We say that foo is block-scoped to the if statement. This means it can only be accessed from within that block.

If we try to access foo outside of the block, we get a ReferenceError because it is out of scope:

if (true) {
    const foo = "foo";
    console.log(foo); // "foo"
}

console.log(foo); // Uncaught ReferenceError: foo is not defined

Block statements in other forms, such as for and while loops, will also create a scope for block-scoped variables. For instance, foo is scoped within a function body below:

function sayFoo() {
    const foo = "foo";
    console.log(foo);
}

sayFoo(); // "foo"

console.log(foo); // Uncaught ReferenceError: foo is not defined

Nested Scopes and Functions

JavaScript allows nested blocks and therefore nested scopes. Nested scopes create a scope tree or scope chain.

Consider the code below, which nests multiple block statements:

if (true) {
    const foo = "foo";
    console.log(foo); // "foo"

    if (true) {
        const bar = "bar";
        console.log(foo); // "foo"

        if (true) {
            console.log(foo, bar); // "foo bar"
        }
    }
}

JavaScript also allows us to nest functions:

function foo(bar) {
    function baz() {
        console.log(bar);
    }

    baz();
}

foo("bar"); // "bar"

As expected, we can access variables from their direct scope (the scope where they get declared). We can also access variables from their inner scopes (the scopes that nest within their direct scope). That is, we can access variables from the scope they get declared in and from every inner scope.

Before we go further, we should clarify the difference in this behavior between variable declaration types.

Scope of let, const, and var in JavaScript

We can create variables with the let, const, and var declarations. For let and const, block scoping works as explained above. However, var behaves differently.

let and const

let and const create block-scoped variables. When declared within a block, they are only accessible within that block. This behavior was demonstrated in our previous examples:

if (true) {
    const foo = "foo";
    console.log(foo); // "foo"
}

console.log(foo); // Uncaught ReferenceError: foo is not defined

var

Variables created with var are scoped to their nearest function or the global scope (which we will discuss shortly). They are not block scoped:

function foo() {
    if (true) {
        var foo = "foo";
    }
    console.log(foo);
}

foo(); // "foo"

var can create confusing situations, and this information is only included for completeness. It is best to use let and const when possible. The rest of this article will pertain only to let and const variables.

If you’re interested in how var behaves in the example above, you should check out my article on hoisting.

Global and Module Scope in JavaScript

In addition to block scopes, variables can be scoped to the global and module scope.

In a web browser, the global scope is at the top level of a script. It is the root of the scope tree that we described earlier, and it contains all other scopes. Thus, creating a variable in the global scope makes it accessible in every scope:

<script>
    const foo = "foo";
</script>
<script>
    console.log(foo); // "foo"

    function bar() {
        if (true) {
            console.log(foo);
        }
    }

    bar(); // "foo"
</script>

Each module also has its own scope. Variables declared at the module level are only available within that module – they are not global:

<script type="module">
    const foo = "foo";
</script>
<script>
    console.log(foo); // Uncaught ReferenceError: foo is not defined
</script>

Closures in JavaScript

Now that we understand scope, let’s go back to the example that we saw in the introduction:

function sayWord(word) {
    return () => console.log(word);
}

const sayHello = sayWord("hello");

sayHello(); // "hello"

Recall that there were two interesting points about this example:

  1. The returned function from sayWord can access the word parameter
  2. The returned function maintains the value of word when sayHello is called outside the scope of word

The first point can be explained by lexical scope: the returned function can access word because it exists in its outer scope.

The second point is because of closures: A closure is a function combined with references to the variables defined outside of it. Closures maintain the variable references, which allow functions to access variables outside of their scope. They “enclose” the function and the variables in its environment.

Examples of Closures in JavaScript

You have probably encountered and used closures frequently without being aware of it. Let’s explore some more ways to use closures.

Callbacks

It is common for a callback to reference a variable declared outside of itself. For example:

function getCarsByMake(make) {
    return cars.filter(x => x.make === make);
}

make is available in the callback because of lexical scoping, and the value of make is persisted when the anonymous function is called by filter because of a closure.

Storing state

We can use closures to return objects from functions that store state. Consider the following makePerson function which returns an object that can store and change a name:

function makePerson(name) {
    let _name = name;

    return {
        setName: (newName) => (_name = newName),
        getName: () => _name,
    };
}

const me = makePerson("Zach");
console.log(me.getName()); // "Zach"

me.setName("Zach Snoek");
console.log(me.getName()); // "Zach Snoek"

This example illustrates how closures do not just freeze the values of variables from a function’s outer scope during creation. Instead, they maintain the references throughout the closure’s lifetime.

Private methods

If you’re familiar with object-oriented programming, you might have noticed that our previous example closely resembles a class that stores private state and exposes public getter and setter methods. We can extend this object-oriented parallel further by using closures to implement private methods:

function makePerson(name) {
    let _name = name;

    function privateSetName(newName) {
        _name = newName;
    }

    return {
        setName: (newName) => privateSetName(newName),
        getName: () => _name,
    };
}

privateSetName is not directly accessible to consumers and it can access the private state variable _name through a closure.

React event handlers

Lastly, closures are common in React event handlers. The following Counter component is modified from the React docs:

function Counter({ initialCount }) {
    const [count, setCount] = React.useState(initialCount);

    return (
        <>
            <button onClick={() => setCount(initialCount)}>Reset</button>
            <button onClick={() => setCount((prevCount) => prevCount - 1)}>
                -
            </button>
            <button onClick={() => setCount((prevCount) => prevCount + 1)}>
                +
            </button>
            <button onClick={() => alert(count)}>Show count</button>
        </>
    );
}

function App() {
    return <Counter initialCount={0} />;
}

Closures make it possible for:

  • the reset, decrement, and increment button click handlers to access setCount
  • the reset button to access initialCount from Counter's props
  • and the “Show count” button to display the count state.

Closures are important in other parts of React, such as props and hooks. Discussion about these topics is out of scope for this article. I recommend reading this post from Kent C. Dodds or this post from Dan Abramov to learn more about the role that closures play in React.

Conclusion

Scope refers to the part of a program where we can access a variable. JavaScript allows us to nest scopes, and variables declared in outer scopes are accessible from all inner ones. Variables can be globally-, module-, or block-scoped.

A closure is a function enclosed with references to the variables in its outer scope. Closures allow functions to maintain connections with outer variables, even outside the scope of the variables.

There are many uses of closures, from creating class-like structures that store state and implement private methods to passing callbacks to event handlers.

Let's connect

If you’re interested in more articles like this, subscribe to my newsletter and connect with me on LinkedIn and Twitter!

Acknowledgements

Thanks to Bryan Smith for providing feedback on drafts of this post.

Cover photo by Karine Avetisyan on Unsplash.

]]> <![CDATA[ JavaScript Closure Tutorial – How Closures and Lexical Scope Work in JS ]]> https://www.freecodecamp.org/news/javascript-closure-lexical-scope/ 66d45e0d230dff01669057cd Mon, 28 Jun 2021 18:45:21 +0000 By Dave Gray

In JavaScript, people often confuse closures with lexical scope.

Lexical scope is an important part of closures, but it is not a closure by itself.

Closures are an advanced concept that is also a frequent topic of technical interviews.

You should have a foundational understanding of functions before attempting to understand closures.

After reading this article, I hope I will have helped you learn the following:

  • The difference between lexical scope and closures.
  • Why closures require lexical scope.
  • How to give an example of a closure during the interview process.

What is Lexical Scope in JavaScript?

Lexical scope describes how nested (also known as "child") functions have access to variables defined in parent scopes.

const myFunction = () => {
     let myValue = 2;
     console.log(myValue);

     const childFunction = () => {
          console.log(myValue += 1);
     }

     childFunction();
}

myFunction();

In this example, childFunction has access to the variable myValue which is defined in the parent scope of myFunction.

The lexical scope of childFunction allows access to the parent scope.

What is a Closure in JavaScript?

w3Schools.com offers a great definition of what a closure is:

A closure is a function having access to the parent scope, even after the parent function has closed.

Let's note the first part of the sentence before the comma:

...a function having access to the parent scope

That's describing lexical scope!

But we need the second part of the definition to give an example of a closure...

...even after the parent function has closed.

Let's look at an example of a closure:

const myFunction = () => {
     let myValue = 2;
     console.log(myValue);

     const childFunction = () => {
          console.log(myValue += 1);
     }

     return childFunction;
}

const result = myFunction();
console.log(result);
result();
result();
result();

Copy the example code above and try it out.

Let's break down what is happening...

In this revision, myFunction returns childFunction instead of calling it.

Therefore, when result is set equal to myFunction(), the console statement inside myFunction is logged, but not the statement inside childFunction.

childFunction is not called into action.

Instead, it is returned and held in result.

In addition, we need to realize that myFunction has closed after it was called.

The line with console.log(result) should show in the console that result now holds the anonymous function value that was childFunction.

Now, when we call result(), we are calling the anonymous function that was assigned to childFunction.

As a child of myFunction, this anonymous function has access to the myValue variable inside myFunction even after it has closed!

The closure we created now allows us to continue to increase the value of the myValue variable every time we call result().

Take Your Time with Closures

Closures are considered to be an advanced concept for good reason.

Even with a step-by-step breakdown of what a closure is, this concept can take time to understand.

Don't rush your understanding and don't be hard on yourself if it doesn't make sense at first.

When you fully understand closure, you may feel like Neo when he sees the Matrix. You'll see new code possibilities and realize they were there all along!

I'll leave you with a tutorial on closures from my YouTube channel. I dive a little deeper and provide a few more examples of closures to build on the discussion in this article.

]]> <![CDATA[ How to Use Closures in JavaScript – A Beginner's Guide ]]> https://www.freecodecamp.org/news/closures-in-javascript/ 66d46012246e57ac83a2c789 Mon, 07 Jun 2021 18:18:01 +0000 By Matías Hernández

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.

Image

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

]]> <![CDATA[ Why You Should Know JavaScript Closures ]]> https://www.freecodecamp.org/news/javascript-closures/ 66d03799ccf811d3117aeedf Tue, 09 Jun 2020 14:00:00 +0000 Fully understanding closures may seem like a right of passage to becoming a JavaScript developer.

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:

Image

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 join the React Bootcamp Click to get started

]]> <![CDATA[ JavaScript Closure Tutorial – With JS Closure Example Code ]]> https://www.freecodecamp.org/news/javascript-closure-tutorial-with-js-closure-example-code/ 66d45d9ba44b8bb91150f655 Wed, 27 May 2020 07:07:44 +0000 By Anchal Nigam

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);

Image

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.

]]> <![CDATA[ Closures in JavaScript Explained with Examples ]]> https://www.freecodecamp.org/news/closures-in-javascript-explained-with-examples/ 66c34760a1d481faeda49b10 Tue, 18 Feb 2020 23:14:00 +0000 What are Closures?

A closure is the combination of a function and the lexical environment (scope) within which that function was declared. Closures are a fundamental and powerful property of Javascript. This article discusses the ‘how’ and ‘why’ about Closures:

Example

//we have an outer function named walk and an inner function named fly

function walk (){

  var dist = '1780 feet';

  function fly(){
    console.log('At '+dist);
  }

  return fly;
}

var flyFunc = walk(); //calling walk returns the fly function which is being assigned to flyFunc
//you would expect that once the walk function above is run
//you would think that JavaScript has gotten rid of the 'dist' var

flyFunc(); //Logs out 'At 1780 feet'
//but you still can use the function as above 
//this is the power of closures

Another Example

function by(propName) {
    return function(a, b) {
        return a[propName] - b[propName];
    }
}

const person1 = {name: 'joe', height: 72};
const person2 = {name: 'rob', height: 70};
const person3 = {name: 'nicholas', height: 66};

const arr_ = [person1, person2, person3];

const arr_sorted = arr_.sort(by('height')); // [ { name: 'nicholas', height: 66 }, { name: 'rob', height: 70 },{ name: 'joe', height: 72 } ]

The closure ‘remembers’ the environment in which it was created. This environment consists of any local variables that were in-scope at the time the closure was created.

function outside(num) {
  var rememberedVar = num; // In this example, rememberedVar is the lexical environment that the closure 'remembers'
  return function inside() { // This is the function which the closure 'remembers'
    console.log(rememberedVar)
  }
}

var remember1 = outside(7); // remember1 is now a closure which contains rememberedVar = 7 in its lexical environment, and //the function 'inside'
var remember2 = outside(9); // remember2 is now a closure which contains rememberedVar = 9 in its lexical environment, and //the function 'inside'

remember1(); // This now executes the function 'inside' which console.logs(rememberedVar) => 7
remember2(); // This now executes the function 'inside' which console.logs(rememberedVar) => 9

Closures are useful because they let you ‘remember’ data and then let you operate on that data through returned functions. This allows javascript to emulate private methods that are found in other programming languages. Private methods are useful for restricting access to code as well as managing your global namespace.

Private variables and methods

Closures can also be used to encapsulate private data/methods. Take a look at this example:

const bankAccount = (initialBalance) => {
  const balance = initialBalance;

  return {
    getBalance: function() {
      return balance;
    },
    deposit: function(amount) {
      balance += amount;
      return balance;
    },
  };
};

const account = bankAccount(100);

account.getBalance(); // 100
account.deposit(10); // 110

In this example, we won’t be able to access balance from anywhere outside of the bankAccount function, which means we’ve just created a private variable. Where’s the closure? Well, think about what bankAccount() is returning. It actually returns an Object with a bunch of functions inside it, and yet when we call account.getBalance(), the function is able to “remember” its initial reference to balance. That is the power of the closure, where a function “remembers” its lexical scope (compile time scope), even when the function is executed outside that lexical scope.

Emulating block-scoped variables.

Javascript did not have a concept of block-scoped variables. Meaning that when defining a variable inside a forloop for example, this variable is visible from outside the forloop as well. So how can closures help us solve this problem ? Let’s take a look.

    var funcs = [];

    for(var i = 0; i < 3; i++){
        funcs[i] = function(){
            console.log('My value is ' + i);  //creating three different functions with different param values.
        }
    }

    for(var j = 0; j < 3; j++){
        funcs[j]();             // My value is 3
                                // My value is 3
                                // My value is 3
    }

Since the variable i does not have block-scope, it’s value within all three functions was updated with the loop counter and created malicious values. Closure can help us solve this issue by creating a snapshot of the environment the function was in when it was created, preserving its state.

    var funcs = [];

    var createFunction = function(val){
        return function() {console.log("My value: " + val);};
    }

    for (var i = 0; i < 3; i++) {
        funcs[i] = createFunction(i);
    }
    for (var j = 0; j < 3; j++) {
        funcs[j]();                 // My value is 0
                                    // My value is 1
                                    // My value is 2
    }

The late versions of javascript es6+ have a new keyword called let which can be used to give the variable a blockscope. There are also many functions (forEach) and entire libraries (lodash.js) that are dedicated to solve such problems as the ones explained above. They can certainly boost your productivity, however it remains extremely important to have knowledge of all these issues when attempting to create something big.

Closures have many special applications that are useful when creating large javascript programs.

  1. Emulating private variables or encapsulation
  2. Making Asynchronous server side calls
  3. Creating a block-scoped variable.

Emulating private variables.

Unlike many other languages, Javascript does not have a mechanism which allows you to create encapsulated instance variables within an object. Having public instance variables can cause a lot of problems when building medium to large programs. However with closures, this problem can be mitigated.

Much like in the previous example, you can build functions which return object literals with methods that have access to the object’s local variables without exposing them. Thus, making them effectively private.

Closures can also help you manage your global namespace to avoid collisions with globally shared data. Usually all global variables are shared between all scripts in your project, which will definitely give you alot of trouble when building medium to large programs. That is why library and module authors use closures to hide an entire module’s methods and data. This is called the module pattern, it uses an immediately invoked function expression which exports only certain functionality to the outside world, significantly reducing the amount of global references.

Here’s a short sample of a module skeleton.

var myModule = (function() = {
    let privateVariable = 'I am a private variable';

    let method1 = function(){ console.log('I am method 1'); };
    let method2 = function(){ console.log('I am method 2, ', privateVariable); };

    return {
        method1: method1,
        method2: method2
    }
}());

myModule.method1(); // I am method 1
myModule.method2(); // I am method 2, I am a private variable

Closures are useful for capturing new instances of private variables contained in the ‘remembered’ environment, and those variables can only be accessed through the returned function or methods.

Vectors

A vector is perhaps the most simple type of collection in Clojure. You can think of it like an array in Javascript. Let’s define a simple vector:

(def a-vector [1 2 3 4 5])
;; Alternatively, use the vector function:
(def another-vector (vector 1 2 3 4 5))
;; You can use commas to separate items, since Clojure treats them as whitespace.
(def comma-vector [1, 2, 3, 4, 5])

You’ll see that it uses square brackets, just like an array in JS. Since Clojure, like JS, is dynamically typed, vectors can hold elements of any type, including other vectors.

(def mixed-type-vector [1 "foo" :bar ["spam" 22] #"^baz$"])

Adding items to a vector

You can append items to a vector using conj. You can also prepend to a list using into, but note that into is intended for merging two vectors, so both its arguments must be vectors, and using into is slower than using conj.

(time (conj [1 2] 3))
; => "Elapsed time: 0.032206 msecs"
;    [1 2 3]
(time (into [1] [2 3]))
; => "Elapsed time: 0.078499 msecs"
;    [1 2 3]

:rocket:

IDEOne it!

Retrieving items from a vector

You can retrieve items from a vector using get. This is equivalent to using bracket notation to access items in an array in many imperative languages. Items in a vector are 0-indexed, counting from the left.

var arr = [1, 2, 3, 4, 5];
arr[0];
// => 1

In Clojure, this would be written like so:

(def a-vector [1 2 3 4 5])
(get a-vector 0)
; => 1

You can also give get a default value, if you give it an index that isn’t in the array.

;; the list doesn't have 2147483647 elements, so it'll return a string instead.
(get a-vector 2147483646 "sorry, not found!")
; => "sorry, not found!"

Converting other collections into vectors

Non-vector data structures can be converted into vectors using the vec function. With hashmaps, this produces a 2D vector containing pairs of keys and values.

(vec '(1 2 3 4 5))
; => [1 2 3 4 5]
(vec {:jack "black" :barry "white"})
; => [[:jack "black"] [:barry "white"]]

When to use a vector?

A vector should be used in almost all cases if you need a collection, because they have the shortest random-access times, which makes it easy to retrieve items from a vector. Note that vectors are ordered. If order doesn’t matter, it may be better to use a set. Also note that vectors are designed for appending items; if you need to prepend items, you might want to use a list.

More info on Closures:

]]> <![CDATA[ A simple guide to help you understand closures in JavaScript ]]> https://www.freecodecamp.org/news/javascript-closures-simplified-d0d23fa06ba4/ 66c358d97ef110ecbf367b2c Tue, 16 Jan 2018 19:10:53 +0000 By Prashant Ram

Closures in JavaScript are one of those concepts that many struggle to get their heads around. In the following article, I will explain in clear terms what a closure is, and I’ll drive the point home using simple code examples.

What is a closure?

A closure is a feature in JavaScript where an inner function has access to the outer (enclosing) function’s variables — a scope chain.

The closure has three scope chains:

  • it has access to its own scope — variables defined between its curly brackets
  • it has access to the outer function’s variables
  • it has access to the global variables

To the uninitiated, this definition might seem like just a whole lot of jargon!

But what really is a closure?

A Simple closure

Let’s look at a simple closure example in JavaScript:

function outer() {

   var b = 10;
   function inner() {

         var a = 20; 
         console.log(a+b);
    }
   return inner;
}

Here we have two functions:

  • an outer function outer which has a variable b, and returns the inner function
  • an inner function inner which has its variable called a, and accesses an outer variable b, within its function body

The scope of variable b is limited to the outer function, and the scope of variable a is limited to the inner function.

Let us now invoke the outer() function, and store the result of the outer() function in a variable X. Let us then invoke the outer() function a second time and store it in variable Y.

function outer() {
  var b = 10;
  function inner() {
    var a = 20;
    console.log(a + b);
  }
  return inner;
}

var X = outer(); //outer() invoked the first time
var Y = outer(); //outer() invoked the second time

Let’s see step-by-step what happens when the outer() function is first invoked:

  1. Variable b is created, its scope is limited to the outer() function, and its value is set to 10.
  2. The next line is a function declaration, so nothing to execute.
  3. On the last line, return inner looks for a variable called inner, finds that this variable inner is actually a function, and so returns the entire body of the function inner.
    [Note that the return statement does not execute the inner function — a function is executed only when followed by () — , but rather the return statement returns the entire body of the function.]
  4. The contents returned by the return statement are stored in X.
    Thus, X will store the following:
    function inner() {
    var a=20;
    console.log(a+b);
    }
  5. Function outer() finishes execution, and all variables within the scope of outer() now no longer exist.

This last part is important to understand. Once a function completes its execution, any variables that were defined inside the function scope cease to exist.

The lifespan of a variable defined inside of a function is the lifespan of the function execution.

What this means is that in console.log(a+b), the variable b exists only during the execution of the the outer() function. Once the outer function has finished execution, the variable b no longer exists.

When the function is executed the second time, the variables of the function are created again, and live only up until the function completes execution.

Thus, when outer() is invoked the second time:

  1. A new variable b is created, its scope is limited to the outer() function, and its value is set to 10.
  2. The next line is a function declaration, so nothing to execute.
  3. return inner returns the entire body of the function inner.
  4. The contents returned by the return statement are stored in Y.
  5. Function outer() finishes execution, and all variables within the scope of outer() now no longer exist.

The important point here is that when the outer() function is invoked the second time, the variable b is created anew. Also, when the outer() function finishes execution the second time, this new variable b again ceases to exist.

This is the most important point to realize. The variables inside the functions only come into existence when the function is running, and cease to exist once the functions completes execution.

Now, let us return to our code example and look at X and Y. Since the outer() function on execution returns a function, the variables X and Y are functions.

This can be easily verified by adding the following to the JavaScript code:

console.log(typeof(X)); //X is of type function
console.log(typeof(Y)); //Y is of type function

Since the variables X and Y are functions, we can execute them. In JavaScript, a function can be executed by adding () after the function name, such as X() and Y().

function outer() {

var b = 10;
   function inner() {

         var a = 20; 
         console.log(a+b);
    }
   return inner;
}

var X = outer(); 
var Y = outer(); 
//end of outer() function executions

X(); // X() invoked the first time
X(); // X() invoked the second time
X(); // X() invoked the third time

Y(); // Y() invoked the first time

When we execute X() and Y(), we are essentially executing the inner function.

Let us examine step-by-step what happens when X() is executed the first time:

  1. Variable a is created, and its value is set to 20.
  2. JavaScript now tries to execute a + b. Here is where things get interesting. JavaScript knows that a exists since it just created it. However, variable b no longer exists. Since b is part of the outer function, b would only exist while the outer() function is in execution. Since the outer() function finished execution long before we invoked X(), any variables within the scope of the outer function cease to exist, and hence variable b no longer exists.

How does JavaScript handle this?

Closures

The inner function can access the variables of the enclosing function due to closures in JavaScript. In other words, the inner function preserves the scope chain of the enclosing function at the time the enclosing function was executed, and thus can access the enclosing function’s variables.

In our example, the inner function had preserved the value of b=10 when the outer() function was executed, and continued to preserve (closure) it.

It now refers to its scope chain and notices that it does have the value of variable b within its scope chain, since it had enclosed the value of b within a closure at the point when the outer function had executed.

Thus, JavaScript knows a=20 and b=10, and can calculate a+b.

You can verify this by adding the following line of code to the example above:

function outer() {

  var b = 10;
  function inner() {

    var a = 20;
    console.log(a + b);
  }
  return inner;
}

var X = outer();

console.dir(X); //use console.dir() instead of console.log()

Open the Inspect element in Google Chrome and go to the Console. You can expand the element to actually see the Closure element (shown in the third to last line below). Notice that the value of b=10 is preserved in the Closure even after the outer() function completes its execution.

Image Variable b=10 is preserved in the Closure, Closures in Javascript

Let us now revisit the definition of closures that we saw at the beginning and see if it now makes more sense.

So the inner function has three scope chains:

  • access to its own scope — variable a
  • access to the outer function’s variables — variable b, which it enclosed
  • access to any global variables that may be defined

Closures in Action

To drive home the point of closures, let’s augment the example by adding three lines of code:

function outer() {

  var b = 10;
  var c = 100;

  function inner() {

    var a = 20;
    console.log("a= " + a + " b= " + b);

    a++;
    b++;

  }
  return inner;
}

var X = outer(); // outer() invoked the first time
var Y = outer();  // outer() invoked the second time
//end of outer() function executions

X(); // X() invoked the first time
X(); // X() invoked the second time
X(); // X() invoked the third time

Y(); // Y() invoked the first time

When you run this code, you will see the following output in the console.log:

a=20 b=10
a=20 b=11
a=20 b=12
a=20 b=10

Let’s examine this code step-by-step to see what exactly is happening and to see closures in Action!

var X = outer();  // outer() invoked the first time

The function outer() is invoked the first time. The following steps take place:

  1. Variable b is created, and is set to 10
    Variable c is created, and set to 100
    Let’s call this b(first_time) and c(first_time) for our own reference.
  2. The inner function is returned and assigned to X
    At this point, the variable b is enclosed within the inner function scope chain as a closure with b=10, since inner uses the variable b.
  3. The outer function completes execution, and all its variables cease to exist. The variable c no longer exists, although the variable b exists as a closure within inner.
var Y= outer();  // outer() invoked the second time
  1. Variable b is created anew and is set to 10
    Variable c is created anew.
    Note that even though outer() was executed once before variables b and c ceased to exist, once the function completed execution they are created as brand new variables.
    Let us call these b(second_time) and c(second_time) for our own reference.
  2. The inner function is returned and assigned to Y
    At this point the variable b is enclosed within the inner function scope chain as a closure with b(second_time)=10, since inner uses the variable b.
  3. The outer function completes execution, and all its variables cease to exist.
    The variable c(second_time) no longer exists, although the variable b(second_time) exists as closure within inner.

Now let’s see what happens when the following lines of code are executed:

X(); // X() invoked the first time
X(); // X() invoked the second time
X(); // X() invoked the third time

Y(); // Y() invoked the first time

When X() is invoked the first time,

  1. variable a is created, and set to 20
  2. the value of a=20, the value of b is from the closure value. b(first_time), so b=10
  3. variables a and b are incremented by 1
  4. X() completes execution and all its inner variables — variable a — cease to exist.
    However, b(first_time) was preserved as the closure, so b(first_time) continues to exist.

When X() is invoked the second time,

  1. variable a is created anew, and set to 20
    Any previous value of variable a no longer exists, since it ceased to exists when X() completed execution the first time.
  2. the value of a=20
    the value of b is taken from the closure value — b(first_time)
    Also note that we had incremented the value of b by 1 from the previous execution, so b=11
  3. variables a and b are incremented by 1 again
  4. X() completes execution and all its inner variables — variable a — cease to exist
    However, b(first_time) is preserved as the closure continues to exist.

When X() is invoked the third time,

  1. variable a is created anew, and set to 20
    Any previous value of variable a no longer exists, since it ceased to exist when X() completed execution the first time.
  2. the value of a=20, the value of b is from the closure value — b(first_time)
    Also note that we had incremented the value of b by 1 in the previous execution, so b=12
  3. variables a and b are incremented by 1 again
  4. X() completes execution, and all its inner variables — variable a — cease to exist
    However, b(first_time) is preserved as the closure continues to exist

When Y() is invoked the first time,

  1. variable a is created anew, and set to 20
  2. the value of a=20, the value of b is from the closure value — b(second_time), so b=10
  3. variables a and b are incremented by 1
  4. Y() completes execution, and all its inner variables — variable a — cease to exist
    However, b(second_time) was preserved as the closure, so b(second_time) continues to exist.

Concluding Remarks

Closures are one of those subtle concepts in JavaScript that are difficult to grasp at first. But once you understand them, you realize that things could not have been any other way.

Hopefully these step-by-step explanations helped you really understand the concept of closures in JavaScript!

Other Articles:

]]>