❯ Scope, Closures & Functions

Roughly 17% of a typical loop — and 17% of the mock exam here.

Scope: three kinds, one lookup rule

var is scoped to the nearest function or module and leaks out of blocks. let and const are scoped to the nearest block. Name resolution is lexical: the engine walks outward from where the code is written, not from who called it, until it finds a binding or reaches the global scope. That is why a closure keeps working long after its creator returned.

Hoisting is often taught badly. All three declaration forms are hoisted; they differ in initialization:

• var is initialized to undefined, so reading it early yields undefined.
• let and const stay uninitialized in the temporal dead zone, so reading them early throws ReferenceError.
• Function declarations are hoisted with their body, so they are callable above their own line. Function expressions and arrow functions are not — the binding exists, the value does not.

One consequence worth remembering: typeof neverDeclared is 'undefined' rather than an error, but typeof x where x is a let in its TDZ still throws.

Closures capture bindings, not values

A closure is a function plus the surrounding bindings it still reaches. Those are live bindings, which explains the interview classic:

for (var i = 0; i < 3; i++) setTimeout(() => console.log(i)); // 3 3 3
for (let i = 0; i < 3; i++) setTimeout(() => console.log(i)); // 0 1 2

With var there is one binding, already 3 by the time any callback runs. With let the spec creates a fresh binding per iteration and copies the value forward before the update expression, so each callback sees its own. Before ES2015 the fix was an IIFE taking i as a parameter.

Closures are also how JavaScript does private state: a factory returning an inner function gives every call its own scope, which is the machinery behind counters, once, memoize, and debounce. In a debounce, the pending timer id must live in the enclosing closure — declare it inside the returned function and clearTimeout cancels nothing.

The leak worth mentioning out loud

A closure keeps everything it captured reachable, and sibling closures created in the same function share one context. A long-lived event handler that captures nothing large can still pin a 50 MB array that a neighbouring closure referenced. Capture the value you need — const size = big.length — and let the big object go out of scope. This is the answer that separates a memorized definition from real experience.

Parameters, defaults, and arity

Defaults are evaluated per call and only when the argument is undefined; f(null) keeps null. Parameters initialize left to right, so a default may reference an earlier parameter but not a later one — function f(a = b, b = 1) throws from the TDZ.

When any parameter has a default, the parameter list gets its own scope, separate from the body. That is why this returns 1, not 99:

function f(cb = () => x, x = 1) { var x = 99; return cb(); }

fn.length counts parameters before the first default or rest parameter — the arity libraries inspect to decide how to call a callback. Rest parameters beat arguments: they are a real array and they work in arrow functions, which have no arguments of their own.

call, apply, bind — and the stack

call and apply invoke immediately and differ only in how arguments are passed; bind returns a new function with this fixed permanently, plus any pre-supplied arguments. A bound function ignores a later call, with new as the one exception.

Two hard details worth having ready: a duplicate let in one block is a SyntaxError caught at parse time, not a runtime error; and V8 has never implemented proper tail calls, so deep recursion throws RangeError: Maximum call stack size exceeded even in tail position. Rewrite as a loop, an accumulator, or a trampoline.