JavaScript Closures Explained with a Real Project Example

If you have been learning JavaScript for a while, you have almost certainly hit a wall called "Closures."

It is the concept that separates junior developers from intermediate ones. It is the favorite topic of technical interviewers. And, quite honestly, it is often explained in the most confusing way possible. You might have read definitions like "a combination of a function and the lexical environment within which that function was declared." While accurate, that sentence doesn't help you build a better website today.

Here is the plain truth: You are probably already using closures without knowing it. Every time you write a click handler, use a React Hook, or set a timer, you rely on this mechanism.

In this guide, we are going to demystify closures. We won't just look at abstract diagrams. We are going to build a real-world project component—a secure, private Shopping Cart module—to see exactly how closures make our code safer and cleaner.

What is a Closure, Really?

Let’s strip away the jargon.

In most programming languages, when a function finishes running, its local variables are destroyed. The computer frees up that memory space for something else. If you declare a variable count inside a function, and that function returns, count is gone.

JavaScript is different.

In JavaScript, if you create a function inside another function, the inner function keeps a permanent link to the outer function’s variables. Even after the outer function has finished executing and returned, the inner function can still access those variables.

Think of it like a backpack.

When a function is created, it packs a backpack containing all the variables that were in scope at the time of its creation. Wherever that function goes, it carries that backpack with it. It can open the backpack and read or modify those variables anytime, even years later.

A Simple "Hello World" of Closures

Before we build the project, let’s look at the classic textbook example to prove the concept.

1function outerFunction() {
2  let outerVariable = "I am from the outer scope!";
3
4  function innerFunction() {
5    console.log(outerVariable);
6  }
7
8  return innerFunction;
9}
10
11const myClosure = outerFunction();
12myClosure(); // Output: "I am from the outer scope!"

Analyze what happened here:

1. outerFunction ran, created a variable, and defined innerFunction.
2. It returned innerFunction and then finished. Technically, outerFunction is dead. Its execution context is gone.
3. We saved the result into myClosure.
4. When we called myClosure(), it successfully logged outerVariable.

How? Because innerFunction was born inside outerFunction, it has a closure (a backpack) containing outerVariable. It remembers where it came from.

Why Do We Actually Need This?

You might be thinking, "That's neat, but why do I care?"

Closures solve a massive problem in JavaScript: State Management and Data Privacy.

JavaScript (until recently with private class fields) didn't have a native way to make variables "private." If you put a variable in the global scope, any part of your code can change it. This is a recipe for bugs.

Imagine you are building a game with a score.

The Bad Way (Global Variable):

1let score = 0;
2
3function addPoint() {
4  score++;
5}

Any script on your page could accidentally type score = 1000 or score = null and break your game.

The Closure Way (Data Privacy): Closures allow us to hide variables so that only specific functions can touch them. This is often called the Module Pattern.

Real Project Example: A Private Shopping Cart

Let's move to a production scenario. You are building an e-commerce site. You need a shopping cart that manages items and calculates the total price.

However, you don't want other parts of the application to be able to mess with the internal cart array directly. You want to force them to use your specific methods like addItem or removeItem. This prevents invalid data (like adding an item with a negative price) from entering your system.

We will build a createCart factory function using closures.

Step 1: The Setup

We define a function that initializes our private variables.

1function createCart() {
2  // These variables are private. 
3  // No code outside this function can access them directly.
4  let items = []; 
5  
6  // We can also have private helper functions
7  function validateItem(item) {
8    return item.price > 0 && item.name;
9  }
10
11  // We return an object containing the "public API"
12  return {
13    addItem: function(newItem) {
14      if (!validateItem(newItem)) {
15        console.log("Error: Invalid item.");
16        return;
17      }
18      items.push(newItem);
19      console.log(`${newItem.name} added to cart.`);
20    },
21
22    getCount: function() {
23      return items.length;
24    },
25
26    getTotal: function() {
27      return items.reduce((total, item) => total + item.price, 0);
28    },
29
30    clearCart: function() {
31      items = []; // We can modify the private variable!
32      console.log("Cart cleared.");
33    }
34  };
35}

Step 2: Using the Module

Now, let’s see how this works in practice.

1const myCart = createCart();
2
3myCart.addItem({ name: "Laptop", price: 1000 }); 
4// Output: Laptop added to cart.
5
6myCart.addItem({ name: "Mouse", price: 50 });  
7// Output: Mouse added to cart.
8
9console.log(myCart.getCount()); // Output: 2
10console.log(myCart.getTotal()); // Output: 1050

Step 3: Proving Privacy

Here is the magic. Try to access the items array directly:

1console.log(myCart.items); 
2// Output: undefined

It is undefined. The items array exists in memory, but the myCart object we returned doesn't have a property named items. It only has the functions (addItem, getTotal, etc.).

Those functions, however, are closures. They were created inside createCart, so they still have access to items. They act as gatekeepers. You can only manipulate the data through the rules defined in those functions.

This is the foundation of many popular libraries. If you have used Redux, the createStore function works on very similar principles. It hides the state and only lets you change it via "dispatch."

Common Use Case: Partial Application (Currying)

Another powerful production use case for closures is creating specialized functions from generic ones. This is often called "Currying" or "Partial Application."

Imagine you are building a website that needs to format dates or currencies in different ways. You can write a factory function that locks in a configuration.

1function createURLBuilder(domain) {
2  return function(path) {
3    return `https://${domain}/${path}`;
4  };
5}
6
7const googleBuilder = createURLBuilder("google.com");
8const mySiteBuilder = createURLBuilder("mysite.com");
9
10console.log(googleBuilder("maps")); 
11// Output: https://google.com/maps
12
13console.log(mySiteBuilder("about-us")); 
14// Output: https://mysite.com/about-us

Here, googleBuilder is a closure that permanently remembers domain was "https://www.google.com/url?sa=E&source=gmail&q=google.com". This makes your code incredibly clean and reusable. You don't have to pass the domain name every single time you want to build a link.

The Famous Loop Interview Question

You cannot write a guide on closures without addressing the "loop problem." This specific scenario trips up thousands of developers and is a staple in job interviews.

The Problem

1for (var i = 1; i <= 3; i++) {
2  setTimeout(function() {
3    console.log("Index: " + i);
4  }, 1000);
5}

Expected Output: Index: 1 Index: 2 Index: 3

Actual Output: Index: 4 Index: 4 Index: 4

Why? The variable i is declared with var, which has function scope (or global scope here). By the time the setTimeout functions actually run (after 1 second), the loop has already finished. The value of i is now 4 (the value that caused the loop to terminate). All three functions share the reference to the same variable i.

The Closure Solution

Before let (block scope) existed, we solved this using an Immediately Invoked Function Expression (IIFE) to create a new closure for every iteration.

1for (var i = 1; i <= 3; i++) {
2  (function(capturedI) {
3    setTimeout(function() {
4      console.log("Index: " + capturedI);
5    }, 1000);
6  })(i);
7}

By wrapping the logic in a function and passing i immediately, we create a new scope—a new "backpack"—for each iteration. capturedI is locked in as 1, then 2, then 3.

Note: In modern JavaScript (ES6+), you should just use let i = 1. let creates a new binding for every loop iteration automatically. But understanding the closure fix demonstrates deep knowledge of the language.

Performance and Memory Leaks

Closures are powerful, but they come with a cost: Memory.

Because a closure keeps a reference to outer variables, the JavaScript Garbage Collector (GC) cannot clean up those variables. As long as the inner function exists, the outer variables must sit in RAM.

In our Shopping Cart example, the items array will stay in memory as long as myCart exists.

How to avoid leaks:

1. Dereference: If you are done with a closure, remove the reference to it. myCart = null. This cuts the link, allowing the Garbage Collector to sweep up the data.
2. Be careful with Event Listeners: If you attach a click listener that is a closure, and you never remove that listener, the variables it captures will stay in memory forever. Always clean up event listeners when components unmount (e.g., in the useEffect cleanup function in React).

Closures in Modern React

If you are a React developer, you are battling closures every day, specifically with Hooks.

The useState and useEffect hooks rely entirely on closures.

1function Counter() {
2  const [count, setCount] = useState(0);
3
4  useEffect(() => {
5    const timer = setInterval(() => {
6      console.log(count); // This might always log 0!
7    }, 1000);
8
9    return () => clearInterval(timer);
10  }, []); // Empty dependency array
11}

In this common bug, the setInterval function is a closure that captured the count variable from the very first render (when count was 0). Even if state updates to 5, this specific closure still has the old "backpack" where count is 0.

This is a "stale closure." We fix it by adding count to the dependency array, which forces the effect to recreate the function (and a new closure) with the fresh data.

FAQ: Common Questions on Closures

Q: Are closures unique to JavaScript? No. Most modern languages support closures, including Python, Ruby, Swift, and C#. However, because JavaScript relies so heavily on callbacks and event-driven programming, they are much more prominent in JS development.

Q: What is the difference between Scope and Closure? Scope is the rules about where variables can be accessed (e.g., "I can see variables in my parent block"). Closure is the mechanism that keeps those variables alive even after the parent block has finished executing.

Q: Can I access the closure variables from the browser console? You cannot access them programmatically in your code (that's the point of privacy!). However, in Chrome DevTools, if you set a breakpoint inside the inner function, you can look at the "Scope" tab on the right side. You will actually see a section labeled Closure containing your hidden variables.

Q: Do I need to use closures now that we have Classes? Classes in JavaScript are often just "syntactic sugar" over closures and prototypes. While Classes are great for structure, closures are still the standard for functional programming patterns, higher-order functions, and lightweight encapsulation.

Conclusion

Closures are not magic tricks designed to make you fail interviews. They are a fundamental part of how JavaScript handles memory and functions.

They allow us to:

1. Encapsulate data (Private variables).
2. Remember state (Stateful functions).
3. Write cleaner code (Partial application/Currying).

The next time you write a function inside another function, pause for a second. Visualize that "backpack" being created. You are not just writing code; you are creating a persistent pocket of memory that will travel with your function wherever it goes.

Mastering this concept is the bridge to advanced JavaScript architecture. Once you see the backpack, you can't unsee it—and your code will be better for it.