You are writing a generic wrapper that logs every call to a method it is given. How do you make sure the wrapped method still receives the correct this, and where does that approach break down?

## The requirement A wrapper is transparent when the target cannot tell it is there. For a method, that includes the receiver: if `obj.save()` used to run with `this === obj`, it must still do so after wrapping. Nothing about a closure gives you that automatically — a wrapper has to capture the receiver at call time and pass it on. ## The correct shape ```js function logged(fn) { return function (...args) { console.log('calling with', args); return fn.apply(this, args); }; } const obj = { name: 'store', save(n) { return this.name + ':' + n; }, }; obj.save = logged(obj.save); obj.save(1); // 'store:1' ``` Two things make it work. The wrapper is declared with the `function` keyword, so it gets its own `this` binding, filled in by whatever call form is used — here the implicit receiver from `obj.save(...)`. And `fn.apply(this, args)` hands that exact value to the target. `fn.call(this, ...args)` is equivalent; with a rest array already in hand, `apply` is the natural fit. ## The two ways to get it wrong **Dropping the receiver.** `return fn(...args)` is a plain call: the target gets no receiver at all. In strict-mode code — which is all module and class code — `this` is then `undefined`, and the first property access throws `TypeError: Cannot read properties of undefined`. In sloppy code it is worse, because `this` silently becomes `globalThis` and the method reads or writes global state instead of failing. **Using an arrow for the wrapper.** An arrow function has no `this` binding of its own; it resolves `this` lexically from where it was written. That is the definition site inside `logged`, not the call site of the wrapper. Assigning the arrow as a method changes nothing — the receiver at the call site is simply discarded. Arrows are the right tool for *capturing* a surrounding receiver and the wrong tool for *forwarding* an incoming one. ```js const broken = (fn) => (...args) => fn.apply(this, args); // `this` is not the caller's ``` ## Where the correct version still falls short Even done right, the wrapper is a different function object, so several observable things change: - **Identity.** `wrapped !== original`. Any registry, cache or set keyed on the function object will not find the original any more, and you cannot remove a handler you registered before wrapping by passing the wrapper. - **Metadata.** A rest-parameter wrapper reports `length` 0 and takes its `name` from the variable it is assigned to, so code that introspects arity or name sees the wrapper. You can repair this deliberately with `Object.defineProperty(wrapped, 'length', { value: fn.length })` and the same for `name`, since both are configurable. - **Construction.** `new wrapped()` does not reproduce `new original()`. The new object gets `wrapped.prototype`, the target runs as an ordinary function against it, and the result fails `instanceof original`. A wrapper meant to cover constructors needs a different technique. - **Property access.** Wrapping a method replaces the value on the object, so getters, setters and non-enumerable or non-writable properties need `Object.getOwnPropertyDescriptor` and `defineProperty` rather than a plain assignment, or you will silently change the shape of the object. - **Async.** Returning `fn.apply(this, args)` propagates the promise correctly, but a timing log must `await` or attach to the returned promise; measuring only the synchronous portion is a classic wrong result. ## The case you cannot fix If the function handed to your wrapper is already hard-bound with `bind`, or is an arrow, forwarding the receiver has no effect: a bound function ignores the receiver it is called with, and an arrow has no receiver slot to fill. Your wrapper still behaves correctly — the target simply does not consult what you passed. This is worth saying out loud in an interview, because it shows you know that receiver control belongs to whoever created the function value, not to whoever calls it. The practical rule for a library is to wrap the *method as declared on the object or prototype*, before anyone binds it, so that the receiver is still live. ## Summary answer Use a non-arrow wrapper, forward with `apply(this, args)`, return the target's value unchanged, and know that identity, arity, name and construction semantics are not preserved for free — and that an already-bound or arrow target makes the forwarding moot.