Given `const counter = { count: 0, inc: () => { this.count++; } }`, why does calling `counter.inc()` fail to increment `counter.count`, and what do you change?

## The rule in one line A regular function gets a fresh `this` on every call, decided by how it was called. An arrow function has no `this` binding at all: the identifier `this` inside an arrow resolves up the scope chain exactly like any other free variable, landing on the `this` of the nearest enclosing ordinary function, class field initializer, method, or — failing all of those — the top-level `this` of the script or module. ## Why the object literal changes nothing The common wrong model is "the arrow is inside the object, so `this` is the object". Object literals are expressions, not scopes. `{ count: 0, inc: () => ... }` introduces no binding for `this`, no variable environment, nothing the scope chain can stop at. The arrow is written in whatever scope the literal itself sits in, and that is where its `this` comes from. ```javascript // top level of an ES module const counter = { count: 0, inc: () => { this.count++; } }; counter.inc(); // TypeError: Cannot read properties of undefined (reading 'count') ``` The error is not about `counter`. It is about the module's top-level `this`, which the spec defines as `undefined`. ## What the outer `this` actually is The failure mode depends on where the literal lives, which is why this bug shows different symptoms in different files: - ES module top level: `this` is `undefined` → TypeError on property access. - Classic script, sloppy mode, top level: `this` is `globalThis` → no error, it quietly increments `globalThis.count`, which starts as `undefined`, so `undefined++` makes it `NaN`. - CommonJS module top level: `this` is `module.exports` → it mutates the exports object. - Inside another ordinary function called plainly under strict mode: `undefined` again. The silent variants are the dangerous ones: no exception, `counter.count` stays `0`, and the state lands somewhere nobody inspects. ## The call form is irrelevant `counter.inc()` is a method call, so the language does compute a receiver — `counter` — and passes it. An arrow function object has no `[[ThisMode]]` that consumes it; the value is discarded. The same is true for `call`, `apply`, `bind`, and the optional `thisArg` of methods like `Array.prototype.map`. Nothing external can redirect an arrow's `this`. That is the point of arrows, and it is exactly wrong for a method, whose whole contract is "operate on whoever called me". ## Fixes Use a function that participates in receiver binding: ```javascript const counter = { count: 0, inc() { this.count++; } // shorthand method — preferred }; counter.inc(); counter.count; // 1 ``` `inc: function () { this.count++; }` behaves identically for this purpose. If you would rather not depend on the receiver at all, close over the object by name: ```javascript const counter = { count: 0 }; counter.inc = () => { counter.count++; }; ``` That version survives extraction — `const f = counter.inc; f();` still works — because it never used `this`. Note the ordering: the arrow can reference `counter` because the reference is resolved when the arrow runs, after the `const` is initialized. ## Where the same rule is a feature The behaviour that breaks methods is what makes arrows the standard callback form. Inside a real method, a nested arrow inherits the method's `this`, so it keeps working where a nested ordinary function would not: ```javascript const counter = { count: 0, incAll(list) { list.forEach(() => { this.count++; }); // `this` is still counter } }; ``` The distinction to carry into an interview: an arrow is right when you want the `this` of the surrounding code, wrong when you want the `this` of the caller. Object methods and prototype methods want the caller's receiver, so they should be ordinary functions. Callbacks handed to other code usually want the surrounding `this`, so they should be arrows. ## Detecting it in review Two grep-able smells: a top-level arrow whose body mentions `this`, and an object literal property written `name: () => ... this ...`. Both are almost always the bug above. Strict mode helps by turning the silent global-mutation variant into a loud TypeError, which is one more reason modules are easier to reason about than classic scripts.