Arrow functions & lexical this

Arrows keep this from where they are written

You met arrow functions in the Arrow functions lesson. They are the short (x) => x * 2 way to write a function. This lesson is about one thing arrows do differently: an arrow does not get its own this.

A quick reminder. this is a special word inside a function. It names the object the function should work on. A regular function gets a new this each time it is called, and the value depends on how you call it. For example, room.show() gives show the object room as its this.

An arrow never gets a new this. It uses the this of the code around it, at the place where the arrow is written.

This is called lexical this. "Lexical" means "decided by where the code is written". You met the same idea in the Scope and Closures lessons: a function finds a variable by looking outward from where it is written. An arrow finds this the same way.

const user = { name: "Asha" };
const readName = () => user.name;
user.name = "Ravi";
console.log(readName());

Line 1 makes a user object. Line 2 makes an arrow that reads user.name. Line 3 changes the name to Ravi. Line 4 calls the arrow, and it prints Ravi. The arrow keeps a link to the user object, not a copy of the old name. A kept this works the same way: the arrow keeps the object itself, so it sees later changes to it.

This makes arrows a good fit for callbacks and timers. A callback is a function you hand to other code, which calls it later. That code often calls it with no object before the dot, so a regular function would get no useful this.

It also makes arrows a bad fit for object methods, and for event listeners that need the clicked element as this. By the end of this lesson, you will know which kind of function to write before you start typing.

The this keyword lesson showed how a regular function gets this from the call. The call site is the place in the code where a function is called. Two examples:

• obj.fn(): the object before the dot, obj, becomes this.
• fn.call(other): call runs fn and sets this to other.

An arrow doesn't look at the call site. Its this is fixed when the arrow is made, by the code around it. The next example makes an arrow inside an object method. Then it uses call to try to give the arrow a different this. Guess what line 10 prints before you step through.

1"use strict";2const room = {Run3  name: "studio",4  makeReader() {5    return () => this.name;6  }7};8 9const reader = room.makeReader();10console.log(reader.call({ name: "garage" }));

Line 10 is the surprise. reader.call({ name: "garage" }) looks like it should set this to the garage object. That works for a regular function. But reader is an arrow. It was made on line 5, while room.makeReader() was running, and inside that method this was room. So the arrow keeps reading room.name and prints studio.

const label = (prefix, name) => prefix + name;
const greet = label.bind({ ignored: true }, "Hello, ");
console.log(greet("Asha"));

Line 2 passes { ignored: true } as the this value, and the arrow ignores it. bind also passes "Hello, ", which fills the first parameter, prefix. So line 3 calls the arrow with prefix set to "Hello, " and name set to "Asha". It prints Hello, Asha.

Every regular function gets a few special names of its own, made new on each call. this is one of them. Here are the others:

• arguments: a list-like object that holds every value passed to the function.
• super: inside a class, a way to reach the parent class's methods.
• new.target: the class or function that new was used with.

An arrow gets none of these. Just like with this, it uses the ones from the function around it.

1function printNames() {2  const readCount = () => arguments.length;3  console.log(readCount());4}5printNames("Asha", "Ravi");

Line 2 makes an arrow inside printNames. The arrow reads arguments.length. The arrow has no arguments of its own, so this is the arguments of printNames. Line 5 passes two values, so line 3 prints 2. This can be handy in a tiny helper. But when you write the function yourself, named parameters are clearer than arguments.

The same is true for super and new.target. An arrow written inside a class constructor uses the constructor's ones. A constructor is the function that runs when you make an object with new.

1"use strict";2function Parent() {}3Parent.prototype.label = function () {4  return "parent";5};6 7class Child extends Parent {8  constructor(first, second) {9    super();10    const readOuterBindings = () => [arguments.length, super.label(), new.target.name];11    console.log(readOuterBindings().join("|"));12  }13}14 15new Child("tea", "toast");

Line 15 runs new Child("tea", "toast"). Inside the constructor, line 10 makes an arrow. The arrow reads three things from the constructor:

• arguments.length is 2, for the two values passed in.
• super.label() calls the parent's label method, which returns parent.
• new.target.name is Child, the class that new was used with.

Line 11 joins the three with | and prints 2|parent|Child.

1const makeUser = () => ({ name: "Asha" });2try {3  new makeUser();4} catch (error) {5  console.log(error.name);6}

Line 3 tries new makeUser(). That throws an error, so line 5 prints the error's name: TypeError.

A callback often runs later, or inside another function. Timers and array methods call your callback for you. They don't call it as timer.callback() or object.callback(). They call it alone, as callback(), with no object before the dot.

In strict mode, a regular function called alone gets this set to undefined. Strict mode is the safer set of rules that "use strict" turns on at the top of the code.

The next example uses a small function called runLater. It calls the callback right away, so you don't have to wait for a real clock. But it calls it the same way a timer does: alone, as callback(). Switch the callback between a regular function and an arrow, and step through each one.

1"use strict";2function runLater(callback) {3  callback();4}5 6const timer = {Run7  label: "Focus",8  seconds: 0,9  start() {10    runLater(function () {11      this.seconds += 1;12      console.log(this.label + ": " + this.seconds);13    });14  }15};16 17try {18  timer.start();19} catch (error) {20  console.log(error.name);21}

With the regular callback: line 18 calls timer.start(), so inside start, this is the timer. But the callback is a separate function. runLater calls it alone, so the callback gets this set to undefined. Line 11 tries to change this.seconds and throws a TypeError.

With the arrow callback: the arrow doesn't get a new this from runLater. It uses the this that start already has, which is the timer. Line 11 adds 1 to seconds, and line 12 prints Focus: 1.

This is why you often see arrows inside setTimeout, setInterval, map, and forEach. You will also see them in promise callbacks, which come later in the course.

Before arrows existed, people kept this in a callback in other ways. You will still see them in older code. The next example writes the same method three ways. All three print JS-1|JS-2|JS-3:

• withArrow (line 6): an arrow callback uses the method's this.
• withSelf (line 9): const self = this saves the method's this in a normal variable. The regular callback reads self instead of this.
• withBind (line 17): .bind(this) makes a copy of the regular callback with this fixed to the method's this.

1"use strict";2const tagger = {3  prefix: "JS-",4  ids: [1, 2, 3],5  withArrow() {6    return this.ids.map((id) => this.prefix + id);7  },8  withSelf() {9    const self = this;10    return this.ids.map(function (id) {11      return self.prefix + id;12    });13  },14  withBind() {15    return this.ids.map(function (id) {16      return this.prefix + id;17    }.bind(this));18  }19};20 21console.log(tagger.withArrow().join("|"));22console.log(tagger.withSelf().join("|"));23console.log(tagger.withBind().join("|"));

The arrow version is the shortest and clearest. It says: use the same this as the method I'm inside.

function makeLabel(prefix) {
  return [1, 2].map((value) => prefix + value);
}
console.log(makeLabel("#").join(","));

An arrow borrows this, but its parameters are still its own. Here map passes each number in as value. prefix comes from makeLabel, the function around the arrow. The output is #1,#2.

Arrows help when a callback inside a method needs the method's this. They hurt when the arrow itself is the method. A method usually needs the object before the dot to become this. An arrow ignores that object.

1"use strict";2function makeCounter() {3  return {4    count: 0,5    inc: () => this.count++6  };7}8 9const counter = makeCounter.call(undefined);10try {11  counter.inc();12} catch (error) {13  console.log(error.name);14}15 16const safeCounter = {17  count: 0,18  inc() {19    this.count++;20    return this.count;21  }22};23console.log(safeCounter.inc());

Line 9 calls makeCounter with this set to undefined. Line 5 makes the arrow inc inside makeCounter, so the arrow's this is undefined too. Line 11 calls counter.inc(), and the arrow ignores counter before the dot. this.count++ tries to read count from undefined. That throws, so line 13 prints TypeError.

Lines 16 to 22 write the method another way. inc() { ... } is method shorthand: a regular function written right inside the object. Line 23 calls safeCounter.inc(), so this is safeCounter. Line 19 adds 1 to its count, and line 23 prints 1.

The table compares the two kinds of function. Read each row as: in this case, what does this become?

There is one place where an arrow method is a good idea: a class field. A class field is a property you write directly in a class body, like count = 0;. Each new object gets its own copy of it.

If the field holds an arrow, like increment = () => ++this.count;, each object gets its own arrow. That arrow is made while the object is being built, so its this is that object. You will see this again in the Losing this lesson and in the Classes lessons. For plain objects written with { }, use method shorthand.

1class Counter {2  count = 0;3  increment = () => ++this.count;4}5 6class ChildCounter extends Counter {}7const first = new Counter();8const second = new Counter();9const child = new ChildCounter();10console.log(first.increment === second.increment);11const detached = first.increment;12console.log(detached());13console.log(child.increment() === 1);

Here is what each line prints:

• Line 10 prints false. first and second each have their own increment arrow, so the two are different functions.
• Line 12 prints 1. Line 11 saved the arrow in detached, away from first. Called alone, it still uses first as this.
• Line 13 prints true. ChildCounter extends Counter, so child gets its own arrow too, and its first call returns 1.

Events come later in the course. But this in event code is too common to skip. An event listener is a function the browser calls when something happens, like a click. You add one with addEventListener.

When the browser calls a regular function listener, it sets this to the element whose listener is running. The event object holds the same element as event.currentTarget.

An arrow listener doesn't get that this from the browser. It keeps the outer this. In React components and JavaScript modules, the outer this is not the button. Click the real button below and compare the two listeners.

1button.addEventListener("click", function (event) {2  console.log(this === event.currentTarget);3});4 5button.addEventListener("click", (event) => {6  console.log(this === event.currentTarget);7  console.log(event.currentTarget.textContent);8});

The simple rule: when in doubt, use event.currentTarget instead of this. It works in a regular listener and in an arrow listener. It keeps working if someone later changes one kind of listener into the other.

1button.addEventListener("click", (event) => {2  event.currentTarget.disabled = true;3  event.currentTarget.textContent = "Saved";4});

Lines 2 and 3 change the button through event.currentTarget. They turn the button off and change its text to Saved.

panel.addEventListener("click", (event) => {
  console.log(event.target === button);
  console.log(event.currentTarget === panel);
});
button.click();

This example only runs on a page where panel holds a button. It uses two names from the event object:

• event.target is the element where the click started. Here that is the button.
• event.currentTarget is the element whose listener is running. Here that is the panel.

Line 5 clicks the button. The click starts at the button, then moves up to the panel, so the panel's listener runs. Line 2 prints true, and line 3 prints true.

The choice is not "arrows are new, regular functions are old". The question to ask is: should this function get this from whoever calls it, or keep the this of the code around it? You will ask it when you write click handlers, change lists of data, set timers, write classes, and write tests.

A helpful habit: say in one sentence which object should be this.

• "This object should do the work." Use method shorthand or a regular function.
• "This inner callback should use the same object as the method around it." Use an arrow.
• No this at all? Use whichever is easiest to read.

Common misconceptions

• "An arrow sets this to itself." No. An arrow has no this of its own. It uses the outer this.
• "bind fixes every function." bind can set this for a regular function. It can't change an arrow's this.
• "Arrows are always the better callback." They are great when you want the outer this. But a regular event listener is the right choice when you want the browser to set this to the element.
• "An arrow method uses the object before the dot." An arrow ignores the dot. Use method shorthand for methods that use this.
• "event.target and event.currentTarget are the same." They are the same for a simple button. But the click can start on an element inside. The element whose listener is running is currentTarget.
• "An arrow gets its own arguments object." No. It uses the arguments of the regular function around it. When you write the function yourself, use named parameters.
• "An arrow gets its own super and new.target." No. It uses the ones from the class method or constructor around it.
• "A class-field arrow is shared by all objects, like a class method." No. Each object gets its own arrow. That uses more memory, but the arrow stays tied to its object.

Key takeaways

• A regular function gets this from how it is called.
• An arrow function gets this from where it is written.
• Use an arrow for a callback that needs the this of the method around it.
• Use method shorthand for object methods that read or change this.
• In event listeners, read event.currentTarget instead of this.

An arrow function has lexical this: it keeps the this of the code around it, instead of getting a new one from each call.

Up next: Losing this.