Week 3: Closures & Lexical Scope

1. What a Closure Actually Is

A closure is a function bundled together with references to the variables from the scope it was created in. In JavaScript, this isn't an opt-in feature — every function forms a closure over its surrounding scope automatically, whether you use that fact or not:

function createCounter() {
  let count = 0; // lives inside createCounter's scope

  return function () {
    count++; // the inner function still has access to `count`
    return count;
  };
}

const counter = createCounter(); // createCounter has already finished running
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

By the time counter() is called, createCounter() has already returned — normally, you'd expect its local variables to be gone. But the inner function that was returned still holds a live reference to count, so it keeps working. That's the whole idea: a closure keeps a variable alive for as long as something still has access to a function that can reach it.

2. Lexical Scoping & the Scope Chain

Closures work because of lexical scoping — a function's scope is determined by where it is written in the source code, not by where or how it's later called. When JavaScript looks up a variable, it walks outward through each enclosing scope until it finds one, forming what's called the scope chain:

const globalValue = "global";

function outer() {
  const outerValue = "outer";

  function inner() {
    const innerValue = "inner";
    // inner() can see all three: innerValue, outerValue, AND globalValue
    console.log(innerValue, outerValue, globalValue);
  }

  inner();
}

outer(); // "inner outer global"

inner() is defined inside outer(), which is defined at the top level — that nesting, fixed at the moment the code was written, is exactly the chain JavaScript walks when resolving a variable name. It doesn't matter that outer and inner might be called from somewhere completely different; the scope chain is locked in by where the functions live in the code, not by the call site. That's the "lexical" part.

3. Practical Closure Patterns

Two shapes cover most real uses of closures: hiding state that shouldn't be directly editable, and generating specialized functions from a shared template.

function createBankAccount(startingBalance) {
  let balance = startingBalance; // not accessible from outside this function at all

  return {
    deposit(amount) {
      balance += amount;
      return balance;
    },
    withdraw(amount) {
      if (amount > balance) throw new Error("Insufficient funds");
      balance -= amount;
      return balance;
    },
    getBalance() {
      return balance;
    },
  };
}

const account = createBankAccount(100);
account.deposit(50);
console.log(account.getBalance()); // 150
console.log(account.balance);      // undefined -- there's no direct way in

balance can only be read or changed through the three methods returned alongside it — there's no property called balance on the returned object at all. This is how JavaScript approximates "private" fields without a real access-modifier keyword: the variable simply isn't reachable from outside the closure that captured it.

function makeMultiplier(factor) {
  return function (n) {
    return n * factor; // factor is captured once, at creation time
  };
}

const double = makeMultiplier(2);
const triple = makeMultiplier(3);

console.log(double(5)); // 10
console.log(triple(5)); // 15

double and triple are both built from the same makeMultiplier template, but each one closed over a different value of factor at the moment it was created — so they behave permanently differently from each other, without needing separate function definitions.

4. The Loop Pitfall

This is the single most common closure bug, and it's a fair interview question precisely because it looks so reasonable at first glance:

for (var i = 1; i <= 3; i++) {
  setTimeout(function () {
    console.log(i);
  }, 100);
}

// Logs: 4, 4, 4 -- not 1, 2, 3!

var is function-scoped (Week 2), not block-scoped — so there is only one i for the entire loop, shared by all three callbacks. By the time any of the setTimeout callbacks actually runs, the loop has already finished and i has already reached 4. All three closures point at that same, final value.

for (let i = 1; i <= 3; i++) {
  setTimeout(function () {
    console.log(i);
  }, 100);
}

// Logs: 1, 2, 3 -- each callback gets its own i

Switching to let is enough to fix it, because let creates a new binding of i for every iteration of the loop — each callback closes over its own separate copy, not one shared variable. This one behavioral difference between var and let is worth remembering on its own; it's the reason this bug simply can't happen with modern declarations.

5. IIFEs (Immediately Invoked Function Expressions)

Before let/const and ES modules existed, JavaScript had no built-in way to create an isolated scope outside of a function — so developers wrote a function and called it immediately, purely to get a private scope:

(function () {
  const secret = "not visible outside this function";
  console.log(secret);
})(); // the trailing () calls it immediately

console.log(typeof secret); // "undefined" -- it never leaked out

The wrapping parentheses around the function are required — without them, JavaScript tries to parse function () {'{'}...{'}'} as a function declaration, which needs a name and can't be called inline like this. Wrapping it in parentheses tells the parser to treat it as an expression instead, which can be invoked immediately with a trailing ().

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.