Arrow functions & lexical this

The sticky-note rule

You already met arrow function syntax in the Arrow functions lesson. This lesson goes deeper on the one arrow feature that changes how real programs feel: arrows do not create their own this. A regular function asks, “who is calling me right now?” every time it runs. An arrow never asks. It uses the this from the place where it was written.

That behavior is called lexical this. The word lexical means “based on where the code is written,” the same idea you saw in Scope and lexical environments and Closures. Variables are found by looking outward through the written scopes. An arrow’s this is found the same way.

That makes arrows wonderful in callbacks and timers, where a regular function is often called later with no useful receiver. It also makes arrows a poor fit for object methods and for event handlers that rely on the browser’s this. By the end, you will know which shape to choose before you type the function.

The this keyword lesson focuses on call-site rules: default, implicit, explicit, and new binding. Regular functions participate in those rules. If you run obj.fn(), the receiver before the dot supplies this. If you run fn.call(other), call supplies it explicitly.

Arrows are different. Their this is chosen when the arrow is created, by the surrounding code. The next experiment creates an arrow inside an object method. Then it tries to use call to relabel the arrow. Predict the output before you step.

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" }));

The surprising line is the last one. reader.call looks as if it should set this to { name: "garage" }. It would work on a regular function. But reader is an arrow that was created while room.makeReader() was running, and that method’s this was room. The arrow keeps reading the room.

Callback code often runs later, or inside another helper. A timer API does not call your callback as timer.callback(). Array methods do not call your callback as object.callback(). They usually call it as a plain function. In strict code, a plain regular-function call has this set to undefined.

The next demo uses a synchronous helper named runLater so you can see the rule without waiting for a real clock. It mimics the important timer behavior: a callback is stored, then invoked as callback(). Switch the callback style and follow the frames.

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, the method call timer.start() correctly gives start a timer-shaped this. But the callback is a separate function. When runLater calls it with no receiver, the callback asks “who called me?” and the answer is “nobody useful.” The update fails.

With the arrow callback, the callback never asks runLater for a new this. It uses the this that start already had. This is the common reason you see arrows inside setTimeout, setInterval, map, forEach, and promise callbacks.

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("|"));

Older code often wrote const self = this before a regular callback, or used .bind(this) after it. Those patterns are still useful to recognize. In modern code, the arrow version is usually shorter and clearer: “use the same this as the method I’m inside.”

The arrow rule helps when an inner callback needs the outer method’s this. It hurts when the arrow itself is supposed to be the method. Object methods normally need the object on the left of the dot to become this. An arrow method ignores that dot.

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());

In the strict factory shown above, the outer this captured by the arrow is undefined. So inc: () => this.count++ does not mean “increment counter.count.” It means “increment count on the outer this,” and there is no outer object to update.

Class fields are the one “method-looking” exception worth knowing: handleClick = () => { ... } creates an arrow per instance, so it captures that instance’s this. That is a bound-method pattern you will see again in Losing this and in the Classes stage. For ordinary object literals, choose method shorthand.

The DOM and events come later in the course, but this in event handlers is too common to ignore. Browsers call a regular addEventListener listener with this set to the element whose listener is running. The event object gives you the same element as event.currentTarget.

Arrow listeners do not receive that browser-provided this. They keep the outer this instead. In React components and ES modules, that outer value is not the button. Click this real button and compare both listener styles.

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 practical rule is simple: use event.currentTarget instead of this when in doubt. It works with a regular listener, an arrow listener, and code that gets refactored later.

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

The choice is not “arrows are modern, regular functions are old.” The choice is “does this function need its own caller-chosen this, or should it keep the surrounding one?” That question appears in UI handlers, data transformations, timers, class components, and tests.

A useful habit is to write the receiver in your sentence. If the sentence is “this object should do the work,” use method shorthand or a regular function. If the sentence is “this inner callback should use the same object as the surrounding method,” use an arrow. If no this is involved, choose the style that is easiest to read.

Common misconceptions

• “Arrows bind this to themselves.” They do the opposite: they have no own this binding.
• “bind fixes every function.” bind fixes regular functions. It cannot change an arrow’s captured this.
• “Arrows are always better callbacks.” They are great when you want lexical this, but a regular event listener is useful when you intentionally want the browser’s this.
• “An arrow method reads the object before the dot.” The dot does not matter to an arrow. Use method shorthand for object behavior.
• “event.target and event.currentTarget are the same.” They match for simple buttons, but child elements can be the target. The listener’s element is currentTarget.

Key takeaways

• Regular functions get this from how they are called.
• Arrow functions get this from where they are written.
• Use arrows for callbacks that need the surrounding method’s this.
• Use method shorthand for object methods that read or write this.
• In event handlers, event.currentTarget is clearer than relying on this.

Arrow functions are functions with lexical this: they keep the surrounding this instead of receiving a new one from the call site.

Up next: Losing this.