this in Arrow Functions
Introduction
Arrow functions do not have their own this. They capture this lexically from the surrounding scope where they are created.
That makes arrows excellent for callbacks that should keep an outer method's receiver, but dangerous as object methods when you expect obj.method() to set this to obj.
Why This Matters
Arrow-related this puzzles are among the most common JavaScript interview questions. Production React, timers, promises, and array callbacks often use arrows specifically to preserve an outer this. But using an arrow as an object method is a classic bug.
Theory
Lexical this
A regular function asks the call site for this. An arrow function does not. It closes over the this value from the nearest surrounding non-arrow scope.
This means call, apply, and bind can pass arguments to an arrow, but they cannot change the arrow's this.
Arrows are great inside methods
A regular method can create an arrow callback. The method gets this from the receiver, and the arrow captures that this for later use. This is why arrows fix many callback bugs.
Arrows are usually bad as object methods
If you write show: () => this.name in an object literal, this is not the object. Object literals do not create this scopes. The arrow captures whatever this was in the surrounding file or function.
Arrows cannot be constructors
Arrow functions do not have [[Construct]] and do not have their own prototype property for instances. Calling an arrow with new throws a TypeError.
Also lexical: arguments and super
Arrows also do not have their own arguments, super, or new.target. For interviews, the headline is still: arrows capture this; they do not bind it dynamically.
Visual Diagrams
user.makeGreeter()
|
+-- regular method call: this === user
|
+-- creates arrow
|
+-- arrow remembers user
greeter.call(other)
|
+-- call supplies other, but arrow ignores it
this is still userAn arrow's `this` is fixed by the surrounding scope where the arrow was created.
Code Examples
Arrow callback preserves the method receiver
The method is regular so it receives user; the nested arrow captures that same receiver.
Do not use arrows for dynamic object methods
This example is wrapped in a factory so the captured this is concrete and visible.
Playground
Press Run to execute the code and see output here.
Output Prediction
Predict the output #1
1const user = {2 name: 'Ada',3 makeGreeter: function () {4 return () => {5 console.log(this.name);6 };7 }8};9 10const greeter = user.makeGreeter();11greeter.call({ name: 'Grace' });Predict the output #2
1function makeTool() {2 return {3 name: 'inner',4 show: () => {5 console.log(this.name);6 }7 };8}9 10const tool = makeTool.call({ name: 'outer' });11tool.show.call({ name: 'call' });Coding Exercises
Convert a callback to preserve this
EasyRefactor makeDelayedLogger so the scheduled callback logs the object's label. Use an arrow for the nested callback and keep makeDelayedLogger as a regular method.
Interview Questions
1How is `this` in an arrow function different from `this` in a regular function?
A regular function gets this dynamically from its call site. An arrow function has no own this; it captures the this value from the surrounding lexical scope. Therefore call, apply, and bind cannot change an arrow's this.
2Why is an arrow function usually a bad object method?
Object literals do not create a this scope. An arrow method captures this from the surrounding scope, not from the object. So obj.arrowMethod() does not make this equal to obj. Use a regular method when the method needs the object as its receiver.
Follow-ups
- When is an arrow inside a method useful?
- Can an arrow function be used with `new`?
Quiz
1. What happens when you call an arrow function with `call` and a `thisArg`?
2. Which pattern is best when a method needs to schedule a callback that reads the method receiver?
Summary
- Arrow functions do not have their own `this`.
- An arrow captures `this` from the surrounding lexical scope.
- `call`, `apply`, and `bind` cannot rebind an arrow's `this`.
- Arrows are useful as callbacks inside regular methods.
- Arrows are usually wrong for object methods that need dynamic receivers.
Cheat Sheet
Arrow this: lexical, captured at creation.
Ignored: call, apply, and bind cannot change arrow this.
Good use: callback inside a regular method.
Bad use: object method that expects obj.method() to set this.
Constructor: arrows cannot be called with new.