How Is this Decided?

The binding is decided by how the function is called, not by where it was written. There are four rules, and they are checked in a fixed order.

// 1. Default binding - a plain call with no receiver.
function plain() { return this === globalThis; }
console.log(plain());   // true in sloppy mode

// 2. Implicit binding - the object before the dot.
const obj = {
  name: "obj",
  method() { return this.name; },
};
console.log(obj.method());   // "obj"

// 3. Explicit binding - call, apply and bind.
console.log(obj.method.call({ name: "other" }));   // "other"

// 4. new binding - the newly created object.
function Point(x) { this.x = x; }
console.log(new Point(3).x);   // 3

// Arrow functions inherit this from the scope they were written in.
const outerThis = this;
const arrow = () => this === outerThis;
console.log(arrow());   // true - the arrow kept the surrounding this

The order matters. If you call a function with the new keyword, the new binding applies. Otherwise, if you used call, apply or bind, the explicit binding applies. Otherwise, if the call had a receiver, the implicit binding applies. Otherwise you fall back to the default binding, which is the global object in sloppy mode and no value at all in strict mode.

The default binding is the one that causes the most confusion, because it changes depending on the mode of the file. The same function called with no receiver gets the global object in sloppy code and nothing in strict code, so code that relies on it can work in one build and break in another.

The arrow function line is the exception to the whole model. An arrow function has no binding of its own, so none of the four rules apply to it. It inherits the this of the scope it was written in, at the moment it was created.

A method has a dynamic this. The this in a method is decided by the call site, so the object you call it on becomes the receiver. An arrow function has a lexical this. It has no binding of its own and inherits the this of the scope it was written in, no matter how it is called later.

The practical consequence is what happens when the function is detached. A method that you pull off the object and call on its own loses its receiver, because there is no longer an object before the dot. An arrow function is unaffected, because it never depended on the call site in the first place.

That makes the two complementary rather than interchangeable. Use a method when the function needs to know what it was called on, such as a button handler that needs to update the button. Use an arrow function when the function needs to keep the context of where it was written, such as a callback created inside a method that has to refer to the same object.

One common mistake to warn about. Using an arrow function as a class method or an object method means the this is the surrounding scope, not the object, and the symptom is usually an error about reading a property of the global object. If you want a method, write it with the method shorthand syntax, and if you want a method plus a callback that keeps the same context, put the arrow function inside the method.

There are a few ways to change the receiver that are less obvious than the four rules, and interviewers like to bring them up.

const obj = {
  name: "obj",
  regular() { return this.name; },
  arrow: () => "no dynamic this",
};

// A method passed as a callback loses its receiver.
const detached = obj.regular;
console.log(detached());          // undefined in strict mode

// Arrow functions keep the scope they were written in.
const arrowDetached = obj.arrow;
console.log(arrowDetached());      // "no dynamic this"

// call and apply set it explicitly.
console.log(obj.regular.call({ name: "explicit" }));   // "explicit"
console.log(obj.regular.apply({ name: "explicit" }));   // "explicit"

// bind creates a new function with the receiver fixed.
const bound = obj.regular.bind({ name: "bound" });
console.log(bound());               // "bound"

// The receiver can even be a primitive, which boxes it.
console.log(obj.regular.call("string receiver"));   // undefined

The last line is the subtle one. When the receiver is a primitive, the language boxes it into a wrapper object before the call. For a string, the wrapper has no name property, so the lookup gives nothing. The primitive itself is not used, and it does not throw.

Two more cases worth knowing. When a method is called from inside another method, the receiver is whatever the inner call used, which is how a chained call like builder.setName("Ada").build() ends up with the right this on each call. And the new binding is a special case of the default one, because the constructor deliberately assigns this to the newly created object.

The summary that helps most is that this is a parameter of the function, chosen by the call site, and the only ways to change it are to change how you call the function or to override it explicitly.