In JavaScript, a function loads a large object and returns a small callback that will be stored for the lifetime of the process. How do you stop that callback from retaining the large object?

## Why "free it later" is not an option JavaScript has no destructor and no deallocation call. The only lever is reachability: an object is reclaimable when nothing reachable points at it. So the question "how do I release this?" always reduces to "what still points at it, and can I stop pointing?". For a long-lived callback, the pointer chain is: whatever holds the callback → the callback's captured environment → the binding → the object. That gives three places to cut, in decreasing order of preference. ## Technique 1: capture the value, not its owner The cheapest and most robust fix is to never put the big thing in the surviving closure's scope chain at all. Derive the small value first. ```js // retains the whole dataset function register(rows) { onTick(() => console.log(rows.length)); } // retains one number function register(rows) { const count = rows.length; onTick(() => console.log(count)); } ``` This also survives refactoring better than the alternatives, because the retained set is obvious from reading the callback: whatever identifiers it mentions. ## Technique 2: shrink the scope the callback is created in If the enclosing function must load the big object for its own work, move that work into its own function so the big binding lives in a scope the surviving callback is not nested inside. ```js function summarize(rows) { // rows is local to summarize return { count: rows.length, first: rows[0]?.id ?? null }; } function register(load) { const summary = summarize(load()); // big array is scoped to summarize's call onTick(() => console.log(summary.count)); } ``` A bare block does *not* achieve this on its own if the callback is created inside the block — the callback's chain then includes the block's record. Scope narrowing only helps when the surviving function sits outside the scope holding the big binding. ## Technique 3: release the binding explicitly When the same scope really must both use the object and produce a surviving callback, assign `null` over it after the last use. ```js function register() { let rows = loadHugeDataset(); const count = rows.length; process(rows); rows = null; // binding still exists, object no longer referenced return () => count; } ``` This works precisely because closures capture *bindings*, not copies: mutating the binding is visible to every closure over that scope, so nulling it genuinely removes the last reference. It needs `let` or `var` rather than `const`, and it is the technique to reach for last, because it is easy to delete by accident in a later refactor and nothing fails loudly when you do. ## Techniques that do not work - `delete rows` — `delete` removes object properties, not variable bindings; in strict mode (and therefore in every module) it is a syntax error on an identifier. - Reassigning a *different* variable that pointed at the same object — you must clear the reference the surviving closure can reach. - Wrapping the object in another object "so it can be dropped" — that adds a hop, not a release, unless you also clear the inner reference. - Calling any "gc" function — there is none in the language, and engine flags that expose one are debugging aids, not an API. ## Argument-level narrowing Destructuring in the parameter list is a real, tidy form of technique 1, because the parameter binding for the whole object never exists: ```js function register({ id, label }) { // the caller's big record is not captured onTick(() => `${id}:${label}`); } ``` Beware, though, that destructuring a property whose *value* is a big structure retains that structure just as firmly — narrowing is about what the extracted values point at, not about the syntax used to extract them. ## How you talk about this in an interview The strong answer names the retained graph explicitly — "the callback keeps its environment, the environment keeps `rows`, `rows` keeps the array" — then picks the cut point closest to the source. Reaching straight for `= null` without first asking whether the callback needed the object at all is the answer that reads as folklore rather than understanding.