Closure patterns

Patterns, not magic

The Closures lesson showed the core rule: a function keeps access to variables from the place where it was created. This lesson turns that rule into practical shapes you will recognize in real code: modules, factories, wrappers, caches, and custom function builders.

We will use a few ideas from earlier lessons: function expressions and callbacks, arrow functions, Map and Set for collection-shaped state, and WeakMap when object-keyed caches should not keep objects alive. Later lessons named Memoization & laziness and Currying & partial application go deeper. The Modules stage explains why ES modules replaced most old module-pattern code.

IIFE means immediately invoked function expression. The classic shape is (function () { ... })();: parentheses turn the function into an expression, then the final parentheses call it. Before ES modules, this was a common way to avoid global pollution in browser scripts.

The module pattern adds one more step: return an object whose methods close over private variables. Think of a shop with a locked back room (count) and a front counter (the returned increment and get methods). Use inline methods in returned objects; that shape is also safer with production minifiers than wiring separately declared local functions onto a local object.

1const counterModule = (function () {Run2  let count = 0;3  console.log("IIFE ran once");4  return {5    increment() {6      count += 1;7      return count;8    },9    get() {10      return count;11    },12  };13})();14 15console.log(counterModule.count);16console.log(counterModule.increment());17console.log(counterModule.increment());18console.log(counterModule.get());

Notice the three important facts: setup printed once, counterModule.count was undefined, and the public methods still changed the private count. Today you usually choose ES modules for file-level privacy and imports, but the old pattern is still worth reading in legacy libraries. The Why modules? lesson later explains that history.

A factory function is a normal function that creates and returns a value, often an object. With closures, each factory call can create private state. A cookie cutter is a good picture: every cookie has the same shape, but each one can carry its own secret recipe card.

1function createAccount(owner, balance) {2  return {3    deposit(amount) {4      balance += amount;5      return balance;6    },7    withdraw(amount) {8      balance -= amount;9      return balance;10    },11    getBalance() {12      return balance;13    },14    label() {15      return owner + ": ₹" + balance;16    },17  };18}19 20const ada = createAccount("Ada", 40);21const grace = createAccount("Grace", 15);22ada.deposit(10);23grace.withdraw(5);24console.log(ada.label());25console.log(grace.label());26console.log(ada.balance);

This style is naturally this-free: the methods use the closed-over balance variable, not this.balance. That avoids binding mistakes when a method is passed around. The trade-off is memory: each factory call creates new closures, and this version creates new method functions per account. Classes with #private fields offer another privacy tool; a later Classes lesson goes deeper.

Closure wrappers are functions that take a function and return a new function with memory. once(fn) is a single-use ticket: the first call punches the ticket and saves the result; later calls return that first result. This is useful for one-time setup, connecting once, or making an initialization API idempotent.

1function once(fn) {2  let called = false;3  let firstResult;4  return function (...args) {5    if (!called) {6      called = true;7      firstResult = fn(...args);8    }9    return firstResult;10  };11}12 13let runs = 0;Run14const welcome = once((name) => {15  runs += 1;16  return "Welcome, " + name;17});18console.log(welcome("Ada"));19console.log(welcome("Grace"));20console.log(runs);

memoize(fn) is a notebook. When you solve a problem, you write down the answer under a key. The next time the same inputs arrive, you read from the notebook instead of doing the work again. In JavaScript, the notebook is often a Map in a closure.

1function memoize(fn) {2  const cache = new Map();3  return function (...args) {4    const key = JSON.stringify(args);5    if (cache.has(key)) return cache.get(key);6    const result = fn(...args);7    cache.set(key, result);8    return result;9  };10}

A function factory returns a configured function. It is a vending machine for tools: put in 3, get a “times three” function; put in "Hello", get a greeting function; put in a range, get a validator. The returned function remembers the configuration through closure.

1function makeMultiplier(factor) {2  return function multiply(number) {3    return number * factor;4  };5}6 7function makeGreeting(greeting) {8  return function greet(name) {9    return greeting + ", " + name + "!";10  };11}12 13function makeValidator({ min, max }) {14  return function isInRange(value) {15    return value >= min && value <= max;16  };17}18 19const triple = makeMultiplier(3);20const hello = makeGreeting("Hello");21const isChildAge = makeValidator({ min: 5, max: 12 });22console.log(triple(7));23console.log(hello("Ada"));24console.log(isChildAge(9));

Function factories are a gentle bridge to more advanced functional programming. Currying & partial application later changes function shapes more formally. For now, focus on the practical habit: put configuration in the outer call, and put changing input in the returned function’s call.

Where you’ll use this

Closure patterns appear whenever you want a small API with memory but do not want to expose the memory itself. UI components can keep counters, form helpers can keep validation settings, and data utilities can remember recent results. The pattern is not tied to the browser; it is plain JavaScript.

1function makeIdGenerator(prefix) {2  let next = 1;3  return function id() {4    const value = prefix + next;5    next += 1;6    return value;7  };8}9 10function createToggle(initial = false) {11  let on = initial;12  return {13    flip() {14      on = !on;15      return on;16    },17    value() {18      return on;19    },20  };21}22 23const memoizedFormat = memoize((amount, currency) =>24  new Intl.NumberFormat("en", { style: "currency", currency }).format(amount),25);

In each case, the caller gets a clean function or object and does not have to manage extra variables. That is the real power of the pattern: a tiny surface area with a remembered interior.

Factories vs classes

Factories and classes can both create many similar things. Pick the one that makes the state, API, and team conventions clearest.

Common misconceptions

• “An IIFE is asynchronous.” It is just a function call. It runs immediately and synchronously.
• “Private means secure from all code.” Closure privacy hides direct access, but public methods still decide what callers can do.
• “Factory calls share one state.” They share code, but each call creates a new lexical environment unless you intentionally close over shared outer data.
• “Memoize is always faster.” It helps repeated expensive calls, but it adds key creation, lookup cost, and memory use.
• “Function factories are currying.” They are related, but this lesson uses a broader practical idea. Currying & partial application is more specific.
• “Closures leak by default.” They keep reachable values alive. That is useful, but long-lived closures with large retained data need care.

Key takeaways

• IIFEs create a temporary scope; module patterns return a public API over private variables.
• Factory functions can create independent closures with private per-instance state.
• once and memoize are wrappers that remember control state or cached answers.
• Function factories put configuration in an outer call and return a custom reusable function.
• Closures are powerful, but every retained value has a memory cost until it is no longer reachable.

Closure patterns are reusable shapes where returned functions remember private variables to make safer, smaller APIs.

Up next: Closures in loops, timers & memory.