Closures made simple

Daniel Ledvina — Fri, 01 May 2026 14:13:25 +0000

⏱️ Reading time: 5 minutes
🎯 Difficulty: Intermediate
📂 Themes: Lexical Scope, Encapsulation, SDK Patterns, Memory Management

What's inside?

The Definition: Demystifying "Lexical Environment" and the Backpack analogy.
What are they for: How closures provide Encapsulation and State Persistence.
The Comparison: A side-by-side look at the "Global Mess" vs. the "Closure Approach."
Production Use Case: Building Secure API Clients to protect sensitive tokens.
Memory leaks: How to prevent Memory Leaks from timers and listeners.
Trade-offs: Understanding memory overhead and debugging complexity.

Closures can be intimidating at first, but if you deep dive into the concept and its connections, it all makes sense right away. Let's get a grasp of what closures are, why they are essential, and how to manage them like a pro.

The Definition

According to MDN:

"A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives a function access to its outer scope."
— MDN Web Docs

That sounds a bit academic, right? Let's clarify that "Lexical" part. In programming, "Lexical" simply means "where it is written in the code." So, a closure is just a function that remembers the physical place where it was born.

If I had to define it in short, I would say:

"An intelligent function with private memory."

Imagine a function that gets "born" inside another function. When the inner function leaves its "parent's house," it packs a backpack full of all the variables it had access to at that moment. Even after the parent function has finished its execution, the inner function carries that backpack wherever it goes.

What are they for?

The primary purpose of a closure is Encapsulation. It allows you to create private variables that cannot be accessed or modified from the outside world. It also enables State Persistence, meaning a function can "remember" data between executions without relying on messy global variables.

In essence, closures allow you to bundle "data" and "logic" together in a tiny, self-contained package.

💡 The React Connection: If you've ever used React Hooks (like useState), you are using closures! React uses a closure to "remember" your state value between re-renders. Even though your component function finishes running completely, the state stays alive in a "backpack" managed by React.

See it in action

To truly appreciate closures, look at how we manage state without them.

❌ Before: The "Global Mess" approach

If you want a counter to remember its value, you might use a global variable. But anyone else's code can accidentally overwrite it.

let count = 0; // Publicly accessible - DANGEROUS

function increment() {
  count++;
  console.log('Current count:', count);
}

increment(); // 1
count = 'Oops, I broke it'; // Someone else's code ruins your logic
increment(); // NaN

Why this approach is problematic:

🚨 Vulnerability: Because the count variable is public, any other part of your application can accidentally or intentionally overwrite it.
🏚️ Fragility: Your logic is brittle. A single line of "rogue" code—such as assigning a string to a variable expected to be a number—permanently breaks the functionality.
☁️ Pollution: As applications grow, global variables lead to "Global Scope Pollution," making it nearly impossible to track which piece of code is responsible for changing a specific value.

✅ After: The "Closure" approach

With a closure, the count variable is "closed" inside the scope. It is safe from outside interference.

function createCounter() {
  let count = 0; // Private memory - SAFE

  return function () {
    count++;
    console.log('Current count:', count);
  };
}

const myCounter = createCounter();
myCounter(); // 1
myCounter(); // 2
// 'count' cannot be accessed or ruined from here!

Why this approach wins:

🔒 Private Memory: The count variable lives only inside the createCounter scope. Once the function is executed, the variable "disappears" from the global perspective.
🔑 Exclusive Access: The only way to interact with the data is through the returned function. This function "remembers" its birthplace and carries that memory in its "backpack" wherever it goes.
🛡️ Security & Integrity: No outside script can access or corrupt the count variable. You have created a secure "black box" where the data and the logic are bundled together.

Real-World Case: Secure API Clients

In production environments (like building a Stripe or Firebase SDK), you often need to handle sensitive data like Access Tokens. Storing these in localStorage makes them vulnerable to XSS attacks.

The "Really Real-World" solution? Use a closure to create a private API client where the sensitive state is physically inaccessible from the global scope.

// This is how modern secure SDKs often handle internal state
function createApiClient(baseUrl, initialToken) {
  // SENSITIVE DATA: This lives only in the closure's "backpack"
  let accessToken = initialToken;

  return {
    async getData(endpoint) {
      console.log(`Fetching from ${baseUrl}${endpoint}...`);

      // The token is used internally here, but never exposed to the outside
      return fetch(`${baseUrl}${endpoint}`, {
        headers: { Authorization: `Bearer ${accessToken}` },
      });
    },
    updateToken(newToken) {
      accessToken = newToken; // Update the private memory safely
    },
  };
}

const client = createApiClient('https://api.mybank.com', 'your_initial_token');

// Works perfectly:
client.getData('/balance');

// SECURE: No rogue script can do this:
console.log(client.accessToken); // undefined
console.log(window.accessToken); // undefined

Why this matters: By using a closure, you've created a hard boundary. The only way to use that token is through the approved getData method. This is a standard pattern for building secure, encapsulated JavaScript libraries.

The Catch: Memory Leaks

A closure is like a "living connection" to its variables. Memory leaks happen when you leave these connections active after you no longer need them. "Similar to subscriptions, you need to sort of 'unsubscribe' from the closure to ensure that memory leakage is not present."

1. The "Zombie" Timer

When you use a closure inside a setInterval, the system keeps that "backpack" alive so it can run every second.

function startHeartbeat(data) {
  return setInterval(() => {
    console.log('Heartbeat for:', data);
  }, 1000);
}

let heartbeat = startHeartbeat('SensitiveData');

// CLEANUP:
clearInterval(heartbeat);
heartbeat = null;

2. The "Sticky" Event Listener

Global objects like window or document stay alive as long as the app is running. If you "glue" a closure to them, it will stay in memory forever unless you manually unstick it.

function trackScroll(componentName) {
  const handler = () => console.log(`Scrolling in ${componentName}`);
  window.addEventListener('scroll', handler);

  // Return a function to "unstick" the listener later
  return () => window.removeEventListener('scroll', handler);
}

const stopTracking = trackScroll('Header');

// When leaving the page:
stopTracking();

3. The "Forgotten" Global Reference

If you store a closure in a variable that lives for a long time, the memory stays locked. Simply tell the Garbage Collector: "I am done with this."

let secureVault = createSecureVault();
// ... later ...
secureVault = null;

Final thought: A closure isn't a memory leak by itself. A leak only happens when you forget to stop the process (Timer, Listener, or Reference) that keeps the closure alive.

Trade-offs

While closures are powerful, they aren't "free":

Memory Overhead: Variables in a closure's "backpack" are not garbage collected while the function exists. In high-performance apps, thousands of closures can cause "Memory Bloat."
Execution Speed: Creating a function inside another function is slightly slower than defining a function on a prototype.
Debugging Complexity: Inspecting private state is harder. You can't just console.log(client) to see the token; you have to use breakpoints.
Testability: If logic is too "private," it can be harder to unit test specific internal states without exposing them.

Conclusion

Closures allow you to write functions that are smart, private, and independent. They are the engine behind React Hooks, Secure SDKs, and elegant Encapsulation. Once you understand that a closure is just a function with a memory, you are good to go.

Disclaimer

The views expressed in this post are based on my personal learning journey. While closures are a standard feature, always ensure you follow your team's specific architectural patterns and performance guidelines to avoid unintended side effects.

Forem: Daniel Ledvina