The Reference type & this

A value and a place to find it

When you write cart.price, JavaScript does two small jobs. First it works out where to look. Then it reads what is there. You almost never notice the first job. This lesson is about that first job, and why it decides what this means inside a method.

const cart = { price: 3 };
console.log(cart.price);

Line 1 makes a cart that holds a price of 3. Line 2 asks for the cart's price and prints 3. Just before the read, JavaScript knows two things: the object to look in (the cart) and the name to look for (price).

The previous spec types lesson showed that the specification describes JavaScript with records like this one. Here you'll see one record answer an everyday question: why does cart.show() know about the cart, but a saved copy of show does not?

Reference Records

An address has a few parts, like a postal address has a street and a house number. The base is the place to start looking, such as the cart. The referenced name is the thing to find there, such as price. There is also a yes-or-no part for strict mode, and one more part that only super uses. These parts live inside the specification. They are not properties on your cart.

const cart = { price: 3 };
const price = cart.price;
console.log(price);

Line 1 makes the cart. Line 2 reads cart.price and keeps the number in a new name, price. Line 3 prints 3. After line 2, price is just the number 3. It does not remember that it came from the cart. The address was used once, for the read, and then it was gone.

Reference Record fields:
[[Base]], [[ReferencedName]], [[Strict]], [[ThisValue]]
// Spec notation, not JavaScript syntax.

This is how the specification writes those parts. You don't need to memorize them; read them like a form. [[Base]] is where to look. It can be an object, an Environment Record (the spec's list of variables in a scope), or "unresolvable", which means nothing was found. [[ReferencedName]] is the name to look up. [[Strict]] says whether strict-mode rules apply. [[ThisValue]] is usually empty; only super fills it in. The full wording is in the ECMAScript Reference Record definition. The block above is a summary, not code you can run.

The address looks different depending on what you wrote. The table below shows the four cases you'll meet. Read each row as: "when I write this, JavaScript looks here, and this is what I get."

The first part of the address, the base, is filled in differently each time. A plain variable such as price is found in a scope, so its base is an Environment Record. You'll meet those in the next lesson. A property such as cart.price uses the cart as its base. A name that doesn't exist anywhere gets the unresolvable base, so JavaScript can report an error instead of guessing.

How a method call chooses this

A member expression is a property access with a dot, like cart.show. Here is the key point. When you write cart.show() with the brackets right after it, JavaScript still has the address in hand when the call starts. The address says "show, inside cart". So the call knows to use cart as this.

const cart = {
  price: 3,
  show() { return this.price; },
};
console.log(cart.show());

Line 1 starts the cart. Line 2 gives it a price of 3. Line 3 adds a show method that returns this.price. Line 5 calls cart.show() and prints 3. You called show through the cart, so this is the cart and this.price is 3.

Let baseValue be ? Evaluation of MemberExpression.
Let propertyNameValue be ? Evaluation of IdentifierName.
Return a Reference Record whose [[Base]] is baseValue.
// Condensed steps from property access evaluation.

The spec's property access steps don't fetch the property straight away. They hand back an address with two parts: the cart and the name show. The outline above skips some details, such as private fields. The address is a way to describe behavior; it is not an object stored in memory.

Let func be ? GetValue(ref).
If IsPropertyReference(thisValueRef) is true,
  let thisValue be GetThisValue(thisValueRef).
Otherwise, let thisValue be undefined.
// Condensed from call evaluation and EvaluateCall.

Now the call itself. EvaluateCall does two things with the address. It uses the address to fetch the function. It also keeps the address to one side and asks, "Which object was this inside?" For cart.show the answer is the cart, so this becomes the cart. If there is no object in the address, this starts as undefined. A strict function keeps undefined. An older non-strict function swaps it for the global object.

1const cart = {Run2  price: 3,3  show() { return this.price; },4};5console.log(cart.show());

Press Step to walk through the replay. You'll see the cart made, the call begin, and the method receive the cart as this. The last step shows the real value the method returned. This replays the example code; it is not a live view inside the engine.

Parentheses, commas, and detaching

Small changes in how you write a call can keep the address or throw it away. Brackets around cart.show only group it, like brackets in maths. They don't read the value early. So the address survives, and the method still gets the cart.

const cart = {
  price: 3,
  show() { return this.price; },
};
console.log((cart.show)());

Lines 1 to 4 make a cart with a show method. Line 5 calls (cart.show)() and prints 3. The extra brackets passed the same address along, so show still read the cart's price.

Return ? Evaluation of Expression.
// Grouping evaluation preserves the Reference result.

The spec's grouping step just hands back whatever was inside. If an address went in, an address comes out. The comma operator is different. It always reads the value on its right before handing it on, so only the value comes out and the address is gone.

"use strict";
const cart = {
  price: 3,
  show() { return this === undefined; },
};
console.log((0, cart.show)());

Line 1 turns on strict mode. Lines 2 to 5 make the cart and a method that checks whether this is undefined. Line 6 works out 0, then cart.show, and calls the function it got. It prints true: the method had no cart, so this was undefined.

Let lval be ? Evaluation of Expression.
Perform ? GetValue(lval).
Let rref be ? Evaluation of AssignmentExpression.
Return ? GetValue(rref).
// Comma operator evaluation.

The comma steps read the value on the right. Reading swaps the address for a plain function, and the fact that it came from the cart is lost before the call starts. Saving the method in a variable does the same thing. The variable holds the function, not the place it came from.

"use strict";
const cart = {
  price: 3,
  show() { return this === undefined; },
};
const show = cart.show;
console.log(show());

Lines 1 to 5 set up the strict example. Line 6 reads cart.show and saves the function as show. Line 7 calls show() by its new name and prints true. Calling a plain name is not the same as calling through the cart.

1"use strict";2const cart = {Run3  price: 3,4  show() { return this === undefined; },5};6const show = cart.show;7console.log(show());

In this replay, watch the function get saved first and then called with no cart. Because the code is strict, this stays undefined. The replay records the real call; it doesn't claim to show the hidden address.

1"use strict";2const cart = {3  price: 3,4  show() { return this === cart; },5};6console.log(cart.show());

Try each call shape in the playground. Member and Grouped print true for this === cart. Comma and Saved print false. Reset goes back to Member. The code line changes with your choice, so you can run each version yourself.

GetValue and PutValue

An address can be used in two ways. GetValue uses it to read: go to the place and bring back what's there. PutValue uses it to write: go to the place and put something new there. Think of a locker. The same locker number lets you take your bag out or put a new bag in.

const cart = { price: 3 };
const price = cart.price;
console.log(price);

Line 1 makes cart.price with the value 3. Line 2 goes to that place, gets 3, and keeps it in price. Line 3 prints 3. Once the read is done, price is only a number. It has forgotten where it came from.

const cart = { price: 3 };
cart.price = 4;
console.log(cart.price);

Line 1 makes the cart. Line 2 puts 4 into cart.price, using the address of that property. Line 3 reads the price again and prints 4. The cart changed. The number 3 itself didn't change; it was replaced.

GetValue(V): if V is not a Reference Record, return V.
If IsUnresolvableReference(V), throw a ReferenceError.
For a property reference, return ? baseObj.[[Get]](name, receiver).
PutValue(V, W): if V is not a Reference Record, throw a ReferenceError.
For a property reference, perform ? baseObj.[[Set]](name, W, receiver).
// Condensed from GetValue and PutValue.

The full GetValue and PutValue steps also handle variables, strict mode, proxies, and errors. The short version above shows only the property path. The object used as this during the read or write matters for getters and setters, and especially for super.

const cart = {
  get price() { console.log("reading price"); return 3; },
};
console.log(cart.price);

Line 1 starts the cart. Line 2 adds a price getter: reading it logs "reading price" and returns 3. Line 4 prints the 3. So a read is not always a simple copy. Sometimes reading runs code, like a shop assistant who checks the stock room before telling you the price.

const cart = { price: 3 };
(cart.price) = 4;
console.log(cart.price);

Line 1 makes the cart. Line 2 writes 4 into (cart.price). The brackets still point at the same place. Line 3 prints 4. Brackets don't read early here either, so the write still knows where to go.

Missing names and typeof

Sometimes the name you ask for doesn't exist. Then the base part of the address says "unresolvable": nothing was found. This is an unresolvable Reference. Reading it throws a ReferenceError. But typeof has a special rule for it, so you can safely ask "does this exist?" It's like asking the front desk whether a guest is staying at the hotel, rather than knocking on a room door that isn't there.

console.log(typeof missingItem);
try {
  console.log(missingItem);
} catch (error) {
  console.log(error.name);
}

Line 1 prints undefined. That is the text typeof gives for a missing name. Line 3 tries to read the name directly. Lines 4 and 5 catch the error and print ReferenceError. Only the direct read failed; typeof did not throw.

If IsUnresolvableReference(value) is true, return "undefined".
// typeof evaluation checks before calling GetValue.

The spec's typeof steps check for an address that leads nowhere before trying to read it. This rule is narrow. A let or const that exists but hasn't been reached yet (its temporal dead zone) still throws ReferenceError, even with typeof.

"use strict";
try {
  missingItem = "tea";
} catch (error) {
  console.log(error.name);
}

Line 1 turns on strict mode. Line 3 tries to write to a name that doesn't exist. Lines 4 and 5 catch the error and print ReferenceError. Old non-strict code would quietly make a new global variable instead. Don't rely on that; it hides typing mistakes.

Super references

super is the one case where the last part of the address gets used. A super Reference splits two jobs apart: where to find the method, and which object the method should work on. It finds the method on the parent class, but it keeps working on the current object.

class Parent {
  show() { return this.name; }
}
class Child extends Parent {
  show() { return super.show(); }
}
console.log(new Child().show.call({ name: "Asha" }));

Lines 1 to 3 make Parent.show, which returns this.name. Lines 4 to 6 make Child.show, which just calls super.show(). Line 7 calls Child's show with an object named Asha as this, and prints Asha. The parent's method worked on that same object.

For a super reference, GetThisValue(V) returns V.[[ThisValue]].
Otherwise it returns V.[[Base]].
// GetThisValue, condensed.

In the spec's GetThisValue steps, a super address answers "who is this?" from its [[ThisValue]] part, not from its [[Base]] part. [[Base]] says where to find show: Parent.prototype. [[ThisValue]] says who show works on: the Asha object. So super never makes the parent this.

The same split applies to getters and setters you inherit. They are found on a parent, but they work on your object. Keep this in mind when you use classes that extend other classes.

Fixing a real callback

Here is where this bites in real apps. A callback is a function you hand over to be run later, for example when a button is clicked. If you hand over cart.show on its own, you hand over only the function. When the button runs it later, the cart is gone. The fix is a small wrapper that calls cart.show() at the right moment.

"use strict";
const cart = {
  price: 3,
  show() { return this.price; },
};
const button = { onclick: () => cart.show() };
console.log(button.onclick());

Line 1 turns on strict mode. Lines 2 to 5 make the cart and its show method. Line 6 saves a small arrow function that calls cart.show(). Line 7 runs it and prints 3. The arrow remembers the cart, and when it runs it makes a normal cart.show() call.

Want more practice with this? The this keyword and Losing this lessons show common call patterns and fixes. Arrow functions and lexical this explains why the arrow wrapper doesn't change this for show. This lesson gives you the reason underneath all of them.

Common mix-ups

The word "reference" means two different things, which causes confusion. People often say a variable holds a "reference" to an object; that just means it points at the object. A spec Reference Record is the short-lived address from this lesson. It only says where to find something, and it disappears right after it is used.

const cart = { price: 3 };
console.log((0, cart.price));

Line 1 makes a cart with price 3. Line 2 works out 0, then cart.price, and prints 3. The comma doesn't delete anything. It reads the value and hands it on, just without the address.

• "Brackets detach a method." No. (cart.show)() keeps the address, so it still uses the cart.
• "A method always remembers its object." No. The way you call it decides this. A saved copy forgets.
• "A bare call always has undefined this." Only in strict code. Older non-strict code uses globalThis.
• "typeof never throws." It is safe for missing names, but a let or const used too early still throws.
• "super makes the parent this." No. It finds the method on the parent but keeps your object as this.

The next two examples show the difference between strict and non-strict code. Both make the same kind of call with no object. Only the strict setting changes, so you can see what that one setting does.

function show() { return this === globalThis; }
const cart = { show };
const detached = cart.show;
console.log(detached());

Line 1 makes a non-strict function that checks whether this is globalThis. Line 2 puts it on the cart. Line 3 saves the function. Line 4 calls it with no cart and prints true. Older non-strict functions fill an empty this with the global object.

"use strict";
function show() { return this === undefined; }
const cart = { show };
const detached = cart.show;
console.log(detached());

Line 1 turns on strict mode. Lines 2 and 3 make the method and put it on the cart. Line 4 saves the function. Line 5 calls it with no cart and prints true for this === undefined. Strict functions leave this empty.

Practice exercises

Guess what each short program does before you run it. The first ones ask for the output. The later ones ask you to fix a button callback and read a parent method. Try a guess first, then use the hints if you get stuck.

const cart = {
  price: 3,
  show() { return this.price; },
};
console.log((cart.show)());

console.log((cart.show)()); // 3

console.log(typeof missingItem);
try {
  console.log(missingItem);
} catch (error) {
  console.log(error.name);
}

// undefined
// ReferenceError

const cart = { price: 3 };
cart.price = 4;
console.log(cart.price);

cart.price = 4;
console.log(cart.price); // 4

"use strict";
const cart = { price: 3, show() { return this.price; } };
const button = { onclick: cart.show };
// Replace onclick with a callback that keeps the cart.
console.log(button.onclick());

button.onclick = () => cart.show();
console.log(button.onclick()); // 3

class Parent {
  show() { return this.name; }
}
class Child extends Parent {
  show() { return super.show(); }
}
console.log(new Child().show.call({ name: "Asha" }));

console.log(new Child().show.call({ name: "Asha" })); // Asha

"use strict";
function show() { return this === undefined; }
const cart = { show };
const detached = cart.show;
console.log(detached());

console.log(detached()); // true

Check your understanding

For each question, ask one thing first: does the call still have the address (a dot call like cart.show()), or just a plain function? For reads and writes, ask whether the code takes a value out or puts one in. Each answer explains why it's right or wrong.

Key takeaways

A method doesn't carry its object around. The way you call it decides whether JavaScript still knows which object to use as this.

• A Reference Record is a short-lived address that says where to find a name or property: [[Base]], [[ReferencedName]], [[Strict]], and [[ThisValue]].
• GetValue uses the address to read. PutValue uses it to write.
• In cart.show(), the address reaches the call, so this is the cart.
• Brackets keep the address. A comma, or saving the method in a variable, throws it away.
• With no object, strict code leaves this undefined; older non-strict code uses globalThis.
• typeof is safe for missing names, and super finds the method on the parent but keeps your object as this.

Coming next: Environment Records: how scope is specified. It explains where plain variable names, like price, are found.