How Do Methods Bind this?

You lose the receiver because the receiver comes from the call site. When you copy a method into a variable and then call that variable, the call looks like a plain function call with no receiver. So this has no value, and the method fails as soon as it tries to use it.

const timer = {
  seconds: 10,
  tick() {
    this.seconds -= 1;
    console.log('ticking, now', this.seconds);
  },
};

const detached = timer.tick;
try {
  detached();
} catch (err) {
  console.log('detached:', err.name);   // 'TypeError' in strict mode
}

// Fix 1: keep the call as a method call.
timer.tick();   // ticking, now 9

// Fix 2: bind the receiver once.
const bound = timer.tick.bind(timer);
bound();        // ticking, now 8

There are several fixes, and picking the right one is a sign of experience.

Call it as a method. This is the simplest fix, and it is the right one when the caller is under your control. Passing timer.tick as a bare function loses the receiver, but passing it as a callback and then calling that callback with the object keeps it.

Bind it. The bind method returns a new function with the receiver permanently attached to it. Use it when you are handing the method to something else that will call it later, such as an event listener or a timer callback.

Use an arrow function. An arrow function takes its this from the scope where it was written, so it works well for callbacks that you create inside a method. It does not work for the method itself, because then it would capture the wrong value.

Use the method shorthand. If you define the method with the shorthand syntax rather than as a function property, it still has a dynamic this. It behaves like a normal method when it is passed around, and you can bind it whenever you need to.

There are three syntaxes in common use, plus a fourth one for computed names. They are not the same thing, and the differences matter when the method is passed around.

const obj = {
  // Method shorthand, which is the recommended form.
  greet() { return 'hi'; },

  // A function property.
  farewell: function () { return 'bye'; },

  // An arrow function property.
  arrow: () => 'arrow',

  // A computed name.
  ['computed' + 'Name']() { return 'computed'; },
};

console.log(obj.greet());          // 'hi'
console.log(obj.farewell());      // 'bye'
console.log(obj.arrow());          // 'arrow'
console.log(obj.computedName());   // 'computed'

The method shorthand and the function property behave in almost the same way. Both get a dynamic this from the call site, both can be called with the new keyword, and both are raised to the top of the object literal before any code runs. The shorthand is preferred because it is shorter, because it reads more clearly at the call site, and because it gives a better name in a stack trace.

The arrow function property is the odd one out. It has no this of its own, so it takes the this of the scope where the object literal was written. That is useful when you want a callback that keeps the surrounding context. It is also a trap when you expected a normal method, because the receiver will quietly be something else entirely.

One more detail about the function property form. The name of the function comes from the property key, so obj.farewell.name is 'farewell' even though the function was written without a name. It is a small detail, but it shows up in debugging output.

For class methods the same rules apply, with one addition. Class methods are always strict, and they are not enumerable, which is the behaviour that you want for methods on a shared prototype.

There are three syntaxes in common use, plus a fourth for computed names. They are not equivalent, and the differences matter when the method is passed around.

const obj = {
  // Method shorthand - the recommended form.
  greet() { return "hi"; },

  // A function property.
  farewell: function () { return "bye"; },

  // An arrow function property.
  arrow: () => "arrow",

  // A computed name.
  ["computed" + "Name"]() { return "computed"; },
};

console.log(obj.greet());          // "hi"
console.log(obj.farewell());      // "bye"
console.log(obj.arrow());          // "arrow"
console.log(obj.computedName());   // "computed"

The method shorthand and the function property behave almost identically. Both get a dynamic this from the call site, both can be called with the new keyword, and both are hoisted within the object literal. The shorthand is preferred because it is shorter, because it reads more clearly at the call site, and because it gives a better stack trace name.

The arrow function property is the odd one out. It has no this of its own, so it inherits the this of the scope where the object literal was written. That is useful when you want a callback that keeps the surrounding context, and it is a trap when you expected a normal method, because the receiver will silently be something else.

One thing to remember about the function property form. The name of the function is inferred from the property key, so obj.farewell.name is "farewell" even though the function was written anonymously. That is a small detail, but it shows up in debugging output.

For class methods the same rules apply, with the addition that class methods are always strict and are not enumerable, which is the behaviour you want for methods on a shared prototype.