What Is a Closure?

A closure is the combination of a function and the environment it was created in. When you create a function inside another function, the inner function keeps a reference to the scope it was defined in, so it can still read those variables after the outer function has returned.

function createCounter() {
  let count = 0;

  return {
    increment() {
      count += 1;
      return count;
    },
    get value() {
      return count;
    },
  };
}

const counter = createCounter();
counter.increment();
counter.increment();
console.log(counter.value);   // 2

const other = createCounter();
console.log(other.value);      // 0 - a separate closure, separate state

The word closure sounds grander than it is. Every function in JavaScript has one. The interesting case is when the function outlives the scope it was written in, because then the variables it captured stay alive instead of being collected.

Two properties make closures powerful. The captured variables are private, so nothing outside can reach in and change them except through the functions you chose to expose. And each call of the outer function creates a fresh set of captured variables, which is why the two counters above are independent.

The cost is memory. A closure keeps its captured environment alive for as long as the function does, so a long-lived callback can hold onto a large object that you thought you had released. This is a real cause of memory leaks in long-running applications, and it is why it is worth thinking about what a callback really holds on to.

A closure captures variables by reference, not by value. The inner function does not get a snapshot of the variable. It gets a live link to the binding, so it sees whatever that binding holds at the moment the function runs.

// The classic loop problem, and the fix.
const handlers = [];

for (var i = 0; i < 3; i++) {
  handlers.push(() => i);
}
console.log(handlers.map((h) => h()));   // [3, 3, 3]

const fixed = [];
for (let j = 0; j < 3; j++) {
  fixed.push(() => j);
}
console.log(fixed.map((h) => h()));   // [0, 1, 2]

The first loop uses var, which is function scoped, so there is one binding called i for the whole loop. Every closure captures that same binding, and by the time you call them the loop has finished and i holds three. All three print three.

The second loop uses let, and let in a loop header creates a fresh binding for each iteration. Each closure captures its own copy, so the values are zero, one and two. That per-iteration binding is the single biggest practical difference between let and var in loops.

Another way to see the live reference is with a value that changes after the closure is created.

let name = "first";
const show = () => name;

console.log(show());   // "first"
name = "second";
console.log(show());   // "second"

That behaviour is sometimes a bug and sometimes a feature. It is what lets a closure observe state that changes, and it is also what makes a closure created inside a loop over a mutable collection dangerous, because by the time the callback runs the collection may have changed.

The factory function pattern is the clearest example: the outer call creates the private state, and the returned function reads and changes it every time it is called.

function makeGreeter(greeting) {
  return (name) => `${greeting}, ${name}!`;
}

const greetHello = makeGreeter("Hello");
const greetHi = makeGreeter("Hi");

console.log(greetHello("Ada"));   // "Hello, Ada!"
console.log(greetHi("Bob"));      // "Hi, Bob!"

// The same idea with state that changes.
function makeCounter() {
  let count = 0;
  return () => ++count;
}

const next = makeCounter();
console.log(next());   // 1
console.log(next());   // 2
console.log(next());   // 3

Each call to makeGreeter creates its own greeting binding, so the two greeters do not interfere. The same is true of makeCounter: each call gets its own count, and the count survives between calls to the returned function because the closure holds on to the environment.

This pattern is the foundation of several things you use every day. A module that exports a configured function is a closure. A middleware function that remembers state between requests is a closure. A memoised function that caches previous results is a closure. And an event handler that remembers which row it belongs to is a closure.

One thing to keep in mind. Because the captured variable is shared by every copy of the returned function, exposing a way to read the state and a way to change it is a deliberate design decision. If the state should be read-only, do not return a setter, and if it should be private, do not return a getter either.