call, apply and bind

## The problem all three solve In JavaScript a function's `this` is not decided when the function is written — it is decided when the function is *called*. `obj.method()` gives `this === obj`, but pulling the same function out and calling it plainly gives something else entirely. `call`, `apply` and `bind` are the language's escape hatch: they let the *caller* state the receiver explicitly rather than letting the call syntax decide it. All three are methods on `Function.prototype`, so every function object inherits them. ## call and apply: same job, different argument shape ```js function greet(greeting, punctuation) { return greeting + ', ' + this.name + punctuation; } const user = { name: 'Ada' }; greet.call(user, 'Hi', '!'); // 'Hi, Ada!' — arguments listed out greet.apply(user, ['Hi', '!']); // 'Hi, Ada!' — arguments in one array ``` The first parameter of each is the `this` value; everything after it is the argument list. `call` takes them as ordinary comma-separated arguments; `apply` takes exactly one further value, an array or array-like object, and spreads it into the parameters. Semantically there is no other difference: both call the function synchronously and return whatever it returns. `apply` earns its keep when the arguments are already sitting in an array and you do not know how many there are: ```js const nums = [3, 1, 4, 1, 5]; Math.max.apply(null, nums); // 5 — Math.max takes separate arguments ``` Since ES2015 the spread syntax `Math.max(...nums)` does the same thing more readably, so new code rarely needs `apply` for this. It still appears when forwarding a whole argument list inside a generic wrapper. ## What happens to the thisArg The treatment of the first argument depends on whether the *called* function is strict: - In strict mode (which includes all module code and class bodies), the value is passed through untouched: `fn.call(null)` really does give `this === null`, and `fn.call(7)` gives the primitive number `7`. - In sloppy mode, `null` and `undefined` are replaced by `globalThis`, and primitives are boxed into wrapper objects, so `this` inside is a `Number` object rather than `7`. This is why `Math.max.apply(null, nums)` is harmless — `Math.max` ignores its receiver entirely — but passing `null` to a function that actually reads `this.something` will throw in strict mode. ## bind: build now, call later ```js const greetAda = greet.bind(user, 'Hi'); greetAda('!'); // 'Hi, Ada!' greetAda('?'); // 'Hi, Ada?' ``` `bind` returns a *new function object*. The original is untouched — `bind` never mutates anything. The returned function remembers two things: the `this` value you supplied, and any arguments you supplied after it, which are prepended to whatever arguments the caller passes later. Nothing runs until you invoke the result. That one difference — returns a function versus invokes immediately — is the whole reason all three exist. When you need to *hand a function to somebody else* (a callback, a stored handler, a value in a table) and still control its receiver, you need `bind`, because `call` and `apply` would have already run it. ## Choosing between them - You have the arguments written out and want to run it now → `call`. - You have the arguments in an array and want to run it now → `apply` (or spread with `call`). - You want a reusable function value with the receiver already decided → `bind`. A common mistake is `element.onclick = handler.call(obj)`, which assigns the *result* of calling `handler` immediately — usually `undefined` — rather than a function. `bind` is what that line wanted. ## Details worth knowing `call` and `apply` return the function's return value, so `Object.prototype.hasOwnProperty.call(obj, 'k')` is a safe way to invoke a method that a particular object might have shadowed or might not inherit at all. `apply` (and spread) build a real argument list, so passing a very large array can exceed the engine's argument limit and throw a `RangeError`; for hundreds of thousands of elements, loop or chunk instead.