Losing this

A method that forgets its object

A method is a function stored inside an object. Inside a method, this means "the object this method is working on". You met this idea in Methods & this.

The last few lessons gave you three rules:

• The this keyword: JavaScript picks this at the moment a function is called, not when it is written.
• call, apply & bind: you can choose this yourself.
• Arrow functions & lexical this: an arrow function has no this of its own. It uses the this from the code around it.

This lesson uses those rules to find and fix one very common bug.

Here is the bug. A method works when you call user.greet(). Then you hand the method to some other code, and it breaks. This is called losing this.

Nothing was deleted. The function still exists, and so does the object. What is missing is the link between them: the call no longer has user in front of the dot.

This lesson covers four places where the bug shows up, in this order:

1. Saving a method in a variable.
2. Handing a method to other code, such as setTimeout.
3. A fix for classes: arrow function fields.
4. A fix for any code: wrapper functions.

For each one, you will run broken code, see the real error or wrong output, and pick the smallest fix.

The smallest version of the bug takes two lines. First, save a method in a variable. Then, call the variable. We say the method is detached: it has been taken off its object.

The variable holds only the function. It does not remember that the function came from user. Step through the code below. You can also switch to two fixed versions and compare.

1"use strict";2const user = {Run3  name: "Ada",4  greet() {5    return "Hi, " + this.name;6  },7};8const fn = user.greet;9console.log(fn());

Read line 8 out loud. const fn = user.greet means "put the function that is stored at user.greet into fn". It does not mean "put a future call of user.greet() into fn". That difference is the whole bug.

Line 9 calls fn(). There is no dot and no object in front of fn. So the method gets no object. When line 5 tries to read this.name, it fails with a TypeError: the error JavaScript throws when you use a value in a way its type does not allow, like reading a property of undefined.

"use strict";
const user = {
  name: "Ada",
  greet() {
    return "Hi, " + this.name;
  },
};
const { greet } = user;
console.log(greet());

Line 8 uses destructuring: a short way to copy a property out of an object into a variable of the same name. const { greet } = user does the same job as const greet = user.greet.

So it is just another way to save the method in a variable. Line 9 calls greet() with nothing in front of it, and it throws the same TypeError.

"use strict";
const user = {
  name: "Ada",
  greet() {
    return "Hi, " + this.name;
  },
};
console.log((user.greet)());

Line 8 puts round brackets around user.greet. These brackets only group. They do not save the function anywhere. The call still reads as user.greet followed by (), so this is user, and it prints Hi, Ada.

This shows that what matters is the line that calls the method, not the line where the method was written.

function showThis() {
  return this === globalThis;
}
const fn = showThis;
console.log(fn());

This small script has no "use strict" line at the top. Strict mode is a safer set of rules that you turn on with that line. Without it, a function called alone gets the global object as its this. The global object holds built-in things such as setTimeout, and globalThis is a name for it. So line 5 prints true.

In strict mode, a function called alone gets undefined as its this instead. Then reading this.name throws a TypeError right away, which makes the bug easy to find.

Outside strict mode, this.name reads a property of the global object. You get a wrong value, often undefined, and no error. So the bug hides for longer.

Modules and classes always use strict mode. Most modern code does too, so you will usually see the TypeError.

A callback is a function you hand to other code, so that code can call it later. The other code decides when to call it and what this it gets.

When you hand over user.greet, you hand over only the function. You do not hand over the call user.greet().

You will see the bug in four common shapes:

• A saved method: const fn = user.greet; fn().
• A timer: setTimeout(user.greet, 0) runs the function later, but not as user.greet().
• An event listener: when a button is clicked, the browser calls your function with the button as this, not your counter object.
• An array callback: [1, 2].forEach(logger.log) calls log once for each item, with no object. forEach takes a second argument, called thisArg, that sets this for each call.

"use strict";
const user = {
  name: "Ada",
  greet() {
    console.log("Timer for " + this.name);
  },
};
const later = user.greet.bind(user);
setTimeout(later, 0);

bind makes a new function whose this is fixed for good. Line 8 makes that new function, later, with this fixed to user.

Line 9 gives later to the timer. When the timer calls it, it prints Timer for Ada. Use this shape when you give the same callback to a timer more than once.

"use strict";
const user = {
  name: "Ada",
  greet(label) {
    return label + ": " + this.name;
  },
};
const later = (label) => user.greet(label);
console.log(later("Welcome"));

A wrapper is a small new function whose only job is to call the method the right way. On line 8, the wrapper takes a label and calls user.greet(label), with user in front of the dot.

So line 9 prints Welcome: Ada. If you handed over user.greet alone, it would lose user before it could use the label.

Now try all four shapes in the lab below. Pick a case and press Run to see the broken result. Then turn the fix on and run it again.

1"use strict";2const user = {3  name: "Ada",4  greet() {5    return "Hi, " + this.name;6  },7};8const fn = user.greet;9console.log(fn());

Run a broken case. Then turn its fix on and run it again.

Classes come later in the course, in Class basics and Private fields & methods. For now, you need only a few facts:

• A class is a recipe for making objects of the same shape.
• new Counter() makes one new object from the Counter recipe. Each object made this way is called an instance.
• A field is a line like count = 0; inside the class. It gives every new instance its own property.

1class Counter {2  count = 0;3  increment = () => {4    this.count++;5  };6}

Line 3 is a field whose value is an arrow function. An arrow function has no this of its own. It uses the this from the code around it. Here, that is the new instance being made.

So each instance gets an increment that is already tied to that instance. You can hand it to a timer or a button, and it still changes the right counter. We call this a bound class field.

The step-through below compares it with a normal class method. A normal method is stored once, on the class's prototype: a shared object that every instance looks in for methods.

1class BoundCounter {Run2  count = 0;3  increment = () => {4    this.count++;5    return this.count;6  };7}8 9class PrototypeCounter {10  count = 0;11  increment() {12    this.count++;13    return this.count;14  }15}16 17const one = new BoundCounter();18const two = new BoundCounter();19const a = new PrototypeCounter();20const b = new PrototypeCounter();21console.log(one.increment === two.increment);22console.log(a.increment === b.increment);

The trace shows a trade-off:

• A normal method is shared by all instances. That saves memory. But it still loses its object when you hand it over.
• A bound class field makes one new function for each instance. That uses a little more memory. But it is safe to hand to timers and event listeners.

Use a bound class field when a method is meant to be used as a callback.

A wrapper is the clearest fix. Instead of handing over the method, you hand over a small new function whose only job is to call the method the right way.

For example, instead of setTimeout(user.greet, 0), write setTimeout(() => user.greet(), 0). The timer calls the wrapper. Then the wrapper calls user.greet(), with user in front of the dot.

You have now seen four fixes. The table below compares them. Each row is one fix: what you write, when it helps most, and what to watch out for.

Sometimes one object has several methods that you hand out as callbacks. Then you can bind them all once, at the start. The helper below does that.

Be careful: the helper changes the object you give it. It replaces each named method with a bound copy.

1function bindMethods(obj, names) {2  for (const name of names) {3    obj[name] = obj[name].bind(obj);4  }5  return obj;6}7 8const cart = bindMethods({9  items: 0,10  add() {11    this.items++;12    return this.items;13  },14}, ["add"]);15 16const addLater = cart.add;17console.log(addLater());

Line by line:

1. Lines 2 and 3 go through each name in the list. For each one, they replace the method with obj[name].bind(obj), a copy whose this is fixed to obj.
2. Lines 8 to 14 make a cart object with an add method, and bind add with the helper.
3. Line 16 saves cart.add in a variable, which would normally lose the object. Line 17 calls it, and it still prints 1, because add was already bound.

When a method gets the wrong this, don't guess. Go through these steps in order:

1. Find the code that finally calls the function. Which object, if any, is in front of the dot?
2. For a moment, add console.log(this) inside the method. In a browser, click the logged value to open it.
3. Add console.trace() inside the method. It prints the list of functions that led to this call, so you can see who called it.
4. Pick the smallest fix: a wrapper, bind, a bound class field, or thisArg.
5. If you use TypeScript, turn on its noImplicitThis setting. It warns you when the type of this is unclear.

Now sort the calls below. Don't sort by where the function was written. Sort by who makes the final call.

Common misconceptions

Each answer explains why it is right or wrong. For each one, find the code that makes the final call.

Key takeaways

• JavaScript picks this when a normal function is called, not when it is written.
• A saved method loses its object: const fn = obj.method; fn().
• Callbacks and timers get only the function. They do not get the object it came from.
• A wrapper, bind, a bound class field, or thisArg each give the method its object back.
• Bound class fields are handy for callbacks, but they make one function for each instance.

Up next: Functions are objects. You will see that functions are values too, so you can store them, give them names, look inside them, and wrap them.