Implement `once(fn)`: a higher-order function returning a wrapper that runs `fn` at most one time and returns that first result on every later call. What must the wrapper get right?

## Why this question is asked `once` is the smallest useful *wrapper*: a higher-order function that takes a function and returns a function with the same calling shape but modified behaviour. Interviewers like it because it is four lines, has a clear specification, and has three separate places to slip. ## A correct implementation ```js function once(fn) { let called = false; let result; return (...args) => { if (!called) { called = true; // set BEFORE invoking result = fn(...args); } return result; // on every call, not just the first }; } const init = once((label) => { console.log('initialising', label); return { ready: true }; }); const a = init('boot'); // logs once, returns { ready: true } const b = init('again'); // logs nothing, returns the SAME object console.log(a === b); // true ``` ## The three things to get right **Forward the arguments.** The wrapper is a stand-in for `fn`, so it must accept whatever callers pass. `(...args) => fn(...args)` forwards any number of arguments. Writing `(x) => fn(x)` quietly truncates every call to one argument, which breaks the moment someone passes two. **Return the cached value on every call.** A tempting version is: ```js // BUG: returns undefined from the second call onward return (...args) => { if (!called) { called = true; return fn(...args); } }; ``` This satisfies "runs once" and violates the more useful part of the contract. Callers that treat `init()` as idempotent — "give me the initialised config, I do not care who initialised it" — now get `undefined` on every call after the first. Whether identity matters is a design decision worth stating: returning the *same* object each time is usually the point. **Guard against reentrancy.** Set the flag before calling `fn`, not after. If `fn` synchronously calls the wrapper again — directly, or through some listener it registers — a flag set afterwards has not been assigned yet, and `fn` runs a second time, possibly recursing. Ordering the two statements correctly costs nothing and removes the hazard. On the reentrant inner call the wrapper returns the current value of `result`, which is still `undefined` because the outer call has not returned yet; that is the honest behaviour, and it is far better than infinite recursion. ## Optional refinements Releasing the reference lets the engine collect anything `fn` was holding: ```js function once(fn) { let result; return (...args) => { if (fn) { result = fn(...args); fn = null; } return result; }; } ``` Here `fn` doubles as the flag. It is neat, but it fails for a caller who legitimately passes `null`-ish values around, and it makes the code slightly harder to read; both versions are defensible in an interview as long as you can say why you chose one. What about a throwing `fn`? With the version above, if `fn` throws, `called` is already `true`, so the wrapper will never retry and every later call returns `undefined`. That may be exactly what you want for a one-shot side effect, or exactly wrong for a lazy initialiser you would like to retry. State the choice out loud: "failures are not retried" is a specification, not an oversight. If retrying is desired, set the flag in a `finally` only on success, or catch and reset. ## Where it is used `once` shows up wherever an action must not be repeated: one-shot initialisation, a cleanup routine that several code paths may reach, a callback that must fire exactly one time even if two events race, a warn-once diagnostic in a library. It is also the seed of a family of related wrappers — a counter-limited `atMost(n, fn)`, a `throttle`, a `memoize` — all built on the same skeleton of "closure holds state, returned function consults it, arguments and return value are forwarded faithfully". ## The wrapper-fidelity principle The general lesson generalises past `once`: when you return a wrapper, decide deliberately what it preserves. Arguments and return value are the minimum. Beyond that, the wrapper is a *different* function object — `wrapped.name` is not `fn.name`, `wrapped.length` is 0 because it declares only a rest parameter, and any properties you attached to `fn` are gone. That rarely matters, but when code introspects functions it matters a lot, and saying so unprompted is what separates a competent answer from a good one.