...
) [ES2018]
this
in
operator: is there a property with a given key?Object.keys()
etc.Object.values()
Object.entries()
[ES2017]Object.fromEntries()
[ES2019]In this book, JavaScript’s style of object-oriented programming (OOP) is introduced in four steps. This chapter covers step 1 and 2; the next chapter covers step 3 and 4. The steps are (fig. 8):
Creating an object via an object literal (starts and ends with a curly brace):
const myObject = { // object literal
myProperty: 1,
myMethod() {
return 2;
, // comma!
}myAccessor() {
get return this.myProperty;
, // comma!
}myAccessor(value) {
set this.myProperty = value;
, // last comma is optional
};
}
.equal(
assert.myProperty, 1
myObject;
).equal(
assert.myMethod(), 2
myObject;
).equal(
assert.myAccessor, 1
myObject;
).myAccessor = 3;
myObject.equal(
assert.myProperty, 3
myObject; )
Being able to create objects directly (without classes) is one of the highlights of JavaScript.
Spreading into objects:
const original = {
a: 1,
b: {
c: 3,
,
};
}
// Spreading (...) copies one object “into” another one:
const modifiedCopy = {
...original, // spreading
d: 4,
;
}
.deepEqual(
assert,
modifiedCopy
{a: 1,
b: {
c: 3,
,
}d: 4,
};
)
// Caveat: spreading copies shallowly (property values are shared)
.a = 5; // does not affect `original`
modifiedCopy.b.c = 6; // affects `original`
modifiedCopy.deepEqual(
assert,
original
{a: 1, // unchanged
b: {
c: 6, // changed
,
},
}; )
We can also use spreading to make an unmodified (shallow) copy of an object:
const exactCopy = {...obj};
Prototypes are JavaScript’s fundamental inheritance mechanism. Even classes are based on it. Each object has null
or an object as its prototype. The latter object can also have a prototype, etc. In general, we get chains of prototypes.
Prototypes are managed like this:
// `obj1` has no prototype (its prototype is `null`)
const obj1 = Object.create(null); // (A)
.equal(
assertObject.getPrototypeOf(obj1), null // (B)
;
)
// `obj2` has the prototype `proto`
const proto = {
protoProp: 'protoProp',
;
}const obj2 = {
__proto__: proto, // (C)
objProp: 'objProp',
}.equal(
assertObject.getPrototypeOf(obj2), proto
; )
Notes:
Each object inherits all the properties of its prototype:
// `obj2` inherits .protoProp from `proto`
.equal(
assert.protoProp, 'protoProp'
obj2;
).deepEqual(
assertReflect.ownKeys(obj2),
'objProp'] // own properties of `obj2`
[; )
The non-inherited properties of an object are called its own properties.
The most important use case for prototypes is that several objects can share methods by inheriting them from a common prototype.
Objects in JavaScript:
There are two ways of using objects in JavaScript:
Fixed-layout objects: Used this way, objects work like records in databases. They have a fixed number of properties, whose keys are known at development time. Their values generally have different types.
const fixedLayoutObject = {
product: 'carrot',
quantity: 4,
; }
Dictionary objects: Used this way, objects work like lookup tables or maps. They have a variable number of properties, whose keys are not known at development time. All of their values have the same type.
const dictionaryObject = {
'one']: 1,
['two']: 2,
[; }
Note that the two ways can also be mixed: Some objects are both fixed-layout objects and dictionary objects.
The ways of using objects influence how they are explained in this chapter:
Let’s first explore fixed-layout objects.
Object literals are one way of creating fixed-layout objects. They are a stand-out feature of JavaScript: we can directly create objects – no need for classes! This is an example:
const jane = {
first: 'Jane',
last: 'Doe', // optional trailing comma
; }
In the example, we created an object via an object literal, which starts and ends with curly braces {}
. Inside it, we defined two properties (key-value entries):
first
and the value 'Jane'
.last
and the value 'Doe'
.Since ES5, trailing commas are allowed in object literals.
We will later see other ways of specifying property keys, but with this way of specifying them, they must follow the rules of JavaScript variable names. For example, we can use first_name
as a property key, but not first-name
). However, reserved words are allowed:
const obj = {
if: true,
const: true,
; }
In order to check the effects of various operations on objects, we’ll occasionally use Object.keys()
in this part of the chapter. It lists property keys:
> Object.keys({a:1, b:2})[ 'a', 'b' ]
Whenever the value of a property is defined via a variable that has the same name as the key, we can omit the key.
function createPoint(x, y) {
return {x, y}; // Same as: {x: x, y: y}
}.deepEqual(
assertcreatePoint(9, 2),
x: 9, y: 2 }
{ ; )
This is how we get (read) a property (line A):
const jane = {
first: 'Jane',
last: 'Doe',
;
}
// Get property .first
.equal(jane.first, 'Jane'); // (A) assert
Getting an unknown property produces undefined
:
.equal(jane.unknownProperty, undefined); assert
This is how we set (write to) a property (line A):
const obj = {
prop: 1,
;
}.equal(obj.prop, 1);
assert.prop = 2; // (A)
obj.equal(obj.prop, 2); assert
We just changed an existing property via setting. If we set an unknown property, we create a new entry:
const obj = {}; // empty object
.deepEqual(
assertObject.keys(obj), []);
.unknownProperty = 'abc';
obj.deepEqual(
assertObject.keys(obj), ['unknownProperty']);
The following code shows how to create the method .says()
via an object literal:
const jane = {
first: 'Jane', // value property
says(text) { // method
return `${this.first} says “${text}”`; // (A)
, // comma as separator (optional at end)
};
}.equal(jane.says('hello'), 'Jane says “hello”'); assert
During the method call jane.says('hello')
, jane
is called the receiver of the method call and assigned to the special variable this
(more on this
in §28.5 “Methods and the special variable this
”). That enables method .says()
to access the sibling property .first
in line A.
An accessor is defined via syntax inside an object literal that looks like methods: a getter and/or a setter (i.e., each accessor has one or both of them).
Invoking an accessor looks like accessing a value property:
A getter is created by prefixing a method definition with the modifier get
:
const jane = {
first: 'Jane',
last: 'Doe',
full() {
get return `${this.first} ${this.last}`;
,
};
}
.equal(jane.full, 'Jane Doe');
assert.first = 'John';
jane.equal(jane.full, 'John Doe'); assert
A setter is created by prefixing a method definition with the modifier set
:
const jane = {
first: 'Jane',
last: 'Doe',
full(fullName) {
set const parts = fullName.split(' ');
this.first = parts[0];
this.last = parts[1];
,
};
}
.full = 'Richard Roe';
jane.equal(jane.first, 'Richard');
assert.equal(jane.last, 'Roe'); assert
Exercise: Creating an object via an object literal
exercises/objects/color_point_object_test.mjs
...
) [ES2018]Inside an object literal, a spread property adds the properties of another object to the current one:
> const obj = {one: 1, two: 2};
> {...obj, three: 3}{ one: 1, two: 2, three: 3 }
const obj1 = {one: 1, two: 2};
const obj2 = {three: 3};
.deepEqual(
assert...obj1, ...obj2, four: 4},
{one: 1, two: 2, three: 3, four: 4}
{; )
If property keys clash, the property that is mentioned last “wins”:
> const obj = {one: 1, two: 2, three: 3};
> {...obj, one: true}{ one: true, two: 2, three: 3 }
> {one: true, ...obj}{ one: 1, two: 2, three: 3 }
All values are spreadable, even undefined
and null
:
> {...undefined}{}
> {...null}{}
> {...123}{}
> {...'abc'}{ '0': 'a', '1': 'b', '2': 'c' }
> {...['a', 'b']}{ '0': 'a', '1': 'b' }
Property .length
of strings and Arrays is hidden from this kind of operation (it is not enumerable; see §28.8.1 “Property attributes and property descriptors [ES5]” for more information).
Spreading includes properties whose keys are symbols (which are ignored by Object.keys()
, Object.values()
and Object.entries()
):
const symbolKey = Symbol('symbolKey');
const obj = {
stringKey: 1,
: 2,
[symbolKey];
}.deepEqual(
assert...obj, anotherStringKey: 3},
{
{stringKey: 1,
: 2,
[symbolKey]anotherStringKey: 3,
}; )
We can use spreading to create a copy of an object original
:
const copy = {...original};
Caveat – copying is shallow: copy
is a fresh object with duplicates of all properties (key-value entries) of original
. But if property values are objects, then those are not copied themselves; they are shared between original
and copy
. Let’s look at an example:
const original = { a: 1, b: {prop: true} };
const copy = {...original};
The first level of copy
is really a copy: If we change any properties at that level, it does not affect the original:
.a = 2;
copy.deepEqual(
assert, { a: 1, b: {prop: true} }); // no change original
However, deeper levels are not copied. For example, the value of .b
is shared between original and copy. Changing .b
in the copy also changes it in the original.
.b.prop = false;
copy.deepEqual(
assert, { a: 1, b: {prop: false} }); original
JavaScript doesn’t have built-in support for deep copying
Deep copies of objects (where all levels are copied) are notoriously difficult to do generically. Therefore, JavaScript does not have a built-in operation for them (for now). If we need such an operation, we have to implement it ourselves.
If one of the inputs of our code is an object with data, we can make properties optional by specifying default values that are used if those properties are missing. One technique for doing so is via an object whose properties contain the default values. In the following example, that object is DEFAULTS
:
const DEFAULTS = {alpha: 'a', beta: 'b'};
const providedData = {alpha: 1};
const allData = {...DEFAULTS, ...providedData};
.deepEqual(allData, {alpha: 1, beta: 'b'}); assert
The result, the object allData
, is created by copying DEFAULTS
and overriding its properties with those of providedData
.
But we don’t need an object to specify the default values; we can also specify them inside the object literal, individually:
const providedData = {alpha: 1};
const allData = {alpha: 'a', beta: 'b', ...providedData};
.deepEqual(allData, {alpha: 1, beta: 'b'}); assert
So far, we have encountered one way of changing a property .alpha
of an object: We set it (line A) and mutate the object. That is, this way of changing a property is destructive.
const obj = {alpha: 'a', beta: 'b'};
.alpha = 1; // (A)
obj.deepEqual(obj, {alpha: 1, beta: 'b'}); assert
With spreading, we can change .alpha
non-destructively – we make a copy of obj
where .alpha
has a different value:
const obj = {alpha: 'a', beta: 'b'};
const updatedObj = {...obj, alpha: 1};
.deepEqual(updatedObj, {alpha: 1, beta: 'b'}); assert
Exercise: Non-destructively updating a property via spreading (fixed key)
exercises/objects/update_name_test.mjs
Object.assign()
[ES6]Object.assign()
is a tool method:
Object.assign(target, source_1, source_2, ···)
This expression assigns all properties of source_1
to target
, then all properties of source_2
, etc. At the end, it returns target
– for example:
const target = { a: 1 };
const result = Object.assign(
,
targetb: 2},
{c: 3, b: true});
{
.deepEqual(
assert, { a: 1, b: true, c: 3 });
result// target was modified and returned:
.equal(result, target); assert
The use cases for Object.assign()
are similar to those for spread properties. In a way, it spreads destructively.
this
Let’s revisit the example that was used to introduce methods:
const jane = {
first: 'Jane',
says(text) {
return `${this.first} says “${text}”`;
,
}; }
Somewhat surprisingly, methods are functions:
.equal(typeof jane.says, 'function'); assert
Why is that? We learned in the chapter on callable values that ordinary functions play several roles. Method is one of those roles. Therefore, internally, jane
roughly looks as follows.
const jane = {
first: 'Jane',
says: function (text) {
return `${this.first} says “${text}”`;
,
}; }
this
Consider the following code:
const obj = {
someMethod(x, y) {
.equal(this, obj); // (A)
assert.equal(x, 'a');
assert.equal(y, 'b');
assert
};
}.someMethod('a', 'b'); // (B) obj
In line B, obj
is the receiver of a method call. It is passed to the function stored in obj.someMethod
via an implicit (hidden) parameter whose name is this
(line A).
How to understand this
The best way to understand this
is as an implicit parameter of ordinary functions (and therefore methods, too).
.call()
Methods are functions and functions have methods themselves. One of those methods is .call()
. Let’s look at an example to understand how this method works.
In the previous section, there was this method invocation:
.someMethod('a', 'b') obj
This invocation is equivalent to:
.someMethod.call(obj, 'a', 'b'); obj
Which is also equivalent to:
const func = obj.someMethod;
.call(obj, 'a', 'b'); func
.call()
makes the normally implicit parameter this
explicit: When invoking a function via .call()
, the first parameter is this
, followed by the regular (explicit) function parameters.
As an aside, this means that there are actually two different dot operators:
obj.prop
obj.prop()
They are different in that (2) is not just (1) followed by the function call operator ()
. Instead, (2) additionally provides a value for this
.
.bind()
.bind()
is another method of function objects. In the following code, we use .bind()
to turn method .says()
into the stand-alone function func()
:
const jane = {
first: 'Jane',
says(text) {
return `${this.first} says “${text}”`; // (A)
,
};
}
const func = jane.says.bind(jane, 'hello');
.equal(func(), 'Jane says “hello”'); assert
Setting this
to jane
via .bind()
is crucial here. Otherwise, func()
wouldn’t work properly because this
is used in line A. In the next section, we’ll explore why that is.
this
pitfall: extracting methodsWe now know quite a bit about functions and methods and are ready to take a look at the biggest pitfall involving methods and this
: function-calling a method extracted from an object can fail if we are not careful.
In the following example, we fail when we extract method jane.says()
, store it in the variable func
, and function-call func
.
const jane = {
first: 'Jane',
says(text) {
return `${this.first} says “${text}”`;
,
};
}const func = jane.says; // extract the method
.throws(
assert=> func('hello'), // (A)
()
{name: 'TypeError',
message: "Cannot read properties of undefined (reading 'first')",
; })
In line A, we are making a normal function call. And in normal function calls, this
is undefined
(if strict mode is active, which it almost always is). Line A is therefore equivalent to:
.throws(
assert=> jane.says.call(undefined, 'hello'), // `this` is undefined!
()
{name: 'TypeError',
message: "Cannot read properties of undefined (reading 'first')",
}; )
How do we fix this? We need to use .bind()
to extract method .says()
:
const func2 = jane.says.bind(jane);
.equal(func2('hello'), 'Jane says “hello”'); assert
The .bind()
ensures that this
is always jane
when we call func()
.
We can also use arrow functions to extract methods:
const func3 = text => jane.says(text);
.equal(func3('hello'), 'Jane says “hello”'); assert
The following is a simplified version of code that we may see in actual web development:
class ClickHandler {
constructor(id, elem) {
this.id = id;
.addEventListener('click', this.handleClick); // (A)
elem
}handleClick(event) {
alert('Clicked ' + this.id);
} }
In line A, we don’t extract the method .handleClick()
properly. Instead, we should do:
const listener = this.handleClick.bind(this);
.addEventListener('click', listener);
elem
// Later, possibly:
.removeEventListener('click', listener); elem
Each invocation of .bind()
creates a new function. That’s why we need to store the result somewhere if we want to remove it later on.
Alas, there is no simple way around the pitfall of extracting methods: Whenever we extract a method, we have to be careful and do it properly – for example, by binding this
or by using an arrow function.
Exercise: Extracting a method
exercises/objects/method_extraction_exrc.mjs
this
pitfall: accidentally shadowing this
Accidentally shadowing this
is only an issue with ordinary functions
Arrow functions don’t shadow this
.
Consider the following problem: when we are inside an ordinary function, we can’t access the this
of the surrounding scope because the ordinary function has its own this
. In other words, a variable in an inner scope hides a variable in an outer scope. That is called shadowing. The following code is an example:
const prefixer = {
prefix: '==> ',
prefixStringArray(stringArray) {
return stringArray.map(
function (x) {
return this.prefix + x; // (A)
;
}),
};
}.throws(
assert=> prefixer.prefixStringArray(['a', 'b']),
()
{name: 'TypeError',
message: "Cannot read properties of undefined (reading 'prefix')",
}; )
In line A, we want to access the this
of .prefixStringArray()
. But we can’t since the surrounding ordinary function has its own this
that shadows (and blocks access to) the this
of the method. The value of the former this
is undefined
due to the callback being function-called. That explains the error message.
The simplest way to fix this problem is via an arrow function, which doesn’t have its own this
and therefore doesn’t shadow anything:
const prefixer = {
prefix: '==> ',
prefixStringArray(stringArray) {
return stringArray.map(
=> {
(x) return this.prefix + x;
;
}),
};
}.deepEqual(
assert.prefixStringArray(['a', 'b']),
prefixer'==> a', '==> b']); [
We can also store this
in a different variable (line A), so that it doesn’t get shadowed:
prefixStringArray(stringArray) {
const that = this; // (A)
return stringArray.map(
function (x) {
return that.prefix + x;
;
}), }
Another option is to specify a fixed this
for the callback via .bind()
(line A):
prefixStringArray(stringArray) {
return stringArray.map(
function (x) {
return this.prefix + x;
.bind(this)); // (A)
}, }
Lastly, .map()
lets us specify a value for this
(line A) that it uses when invoking the callback:
prefixStringArray(stringArray) {
return stringArray.map(
function (x) {
return this.prefix + x;
,
}this); // (A)
, }
this
If we follow the advice in §25.3.4 “Recommendation: prefer specialized functions over ordinary functions”, we can avoid the pitfall of accidentally shadowing this
. This is a summary:
Use arrow functions as anonymous inline functions. They don’t have this
as an implicit parameter and don’t shadow it.
For named stand-alone function declarations we can either use arrow functions or function declarations. If we do the latter, we have to make sure this
isn’t mentioned in their bodies.
this
in various contexts (advanced)What is the value of this
in various contexts?
Inside a callable entity, the value of this
depends on how the callable entity is invoked and what kind of callable entity it is:
this === undefined
(in strict mode)this
is same as in surrounding scope (lexical this
)this
is receiver of callnew
: this
refers to the newly created instanceWe can also access this
in all common top-level scopes:
<script>
element: this === globalThis
this === undefined
this === module.exports
Tip: pretend that this
doesn’t exist in top-level scopes
I like to do that because top-level this
is confusing and there are better alternatives for its (few) use cases.
The following kinds of optional chaining operations exist:
?.prop // optional fixed property getting
obj?.[«expr»] // optional dynamic property getting
obj?.(«arg0», «arg1») // optional function or method call func
The rough idea is:
undefined
nor null
, then perform the operation after the question mark.undefined
.Each of the three syntaxes is covered in more detail later. These are a few first examples:
> null?.propundefined
> {prop: 1}?.prop1
> null?.(123)undefined
> String?.(123)'123'
Consider the following data:
const persons = [
{surname: 'Zoe',
address: {
street: {
name: 'Sesame Street',
number: '123',
,
},
},
}
{surname: 'Mariner',
,
}
{surname: 'Carmen',
address: {
,
},
}; ]
We can use optional chaining to safely extract street names:
const streetNames = persons.map(
=> p.address?.street?.name);
p .deepEqual(
assert, ['Sesame Street', undefined, undefined]
streetNames; )
The nullish coalescing operator allows us to use the default value '(no name)'
instead of undefined
:
const streetNames = persons.map(
=> p.address?.street?.name ?? '(no name)');
p .deepEqual(
assert, ['Sesame Street', '(no name)', '(no name)']
streetNames; )
The following two expressions are equivalent:
?.prop
o!== undefined && o !== null) ? o.prop : undefined (o
Examples:
.equal(undefined?.prop, undefined);
assert.equal(null?.prop, undefined);
assert.equal({prop:1}?.prop, 1); assert
The following two expressions are equivalent:
?.[«expr»]
o!== undefined && o !== null) ? o[«expr»] : undefined (o
Examples:
const key = 'prop';
.equal(undefined?.[key], undefined);
assert.equal(null?.[key], undefined);
assert.equal({prop:1}?.[key], 1); assert
The following two expressions are equivalent:
?.(arg0, arg1)
f!== undefined && f !== null) ? f(arg0, arg1) : undefined (f
Examples:
.equal(undefined?.(123), undefined);
assert.equal(null?.(123), undefined);
assert.equal(String?.(123), '123'); assert
Note that this operator produces an error if its left-hand side is not callable:
.throws(
assert=> true?.(123),
() TypeError);
Why? The idea is that the operator only tolerates deliberate omissions. An uncallable value (other than undefined
and null
) is probably an error and should be reported, rather than worked around.
In a chain of property gettings and method invocations, evaluation stops once the first optional operator encounters undefined
or null
at its left-hand side:
function invokeM(value) {
return value?.a.b.m(); // (A)
}
const obj = {
a: {
b: {
m() { return 'result' }
}
};
}.equal(
assertinvokeM(obj), 'result'
;
).equal(
assertinvokeM(undefined), undefined // (B)
; )
Consider invokeM(undefined)
in line B: undefined?.a
is undefined
. Therefore we’d expect .b
to fail in line A. But it doesn’t: The ?.
operator encounters the value undefined
and the evaluation of the whole expression immediately returns undefined
.
This behavior differs from a normal operator where JavaScript always evaluates all operands before evaluating the operator. It is called short-circuiting. Other short-circuiting operators are:
(a && b)
: b
is only evaluated if a
is truthy.(a || b)
: b
is only evaluated if a
is falsy.(c ? t : e)
: If c
is truthy, t
is evaluated. Otherwise, e
is evaluated.Optional chaining also has downsides:
An alternative to optional chaining is to extract the information once, in a single location:
With either approach, it is possible to perform checks and to fail early if there are problems.
Further reading:
?.
)?Are you occasionally unsure if the optional chaining operator starts with a dot (.?
) or a question mark (?.
)? Then this mnemonic may help you:
?
) the left-hand side is not nullish.
) access a property.o?.[x]
and f?.()
?The syntaxes of the following two optional operator are not ideal:
?.[«expr»] // better: obj?[«expr»]
obj?.(«arg0», «arg1») // better: func?(«arg0», «arg1») func
Alas, the less elegant syntax is necessary because distinguishing the ideal syntax (first expression) from the conditional operator (second expression) is too complicated:
?['a', 'b', 'c'].map(x => x+x)
obj? ['a', 'b', 'c'].map(x => x+x) : [] obj
null?.prop
evaluate to undefined
and not null
?The operator ?.
is mainly about its right-hand side: Does property .prop
exist? If not, stop early. Therefore, keeping information about its left-hand side is rarely useful. However, only having a single “early termination” value does simplify things.
Objects work best as fixed-layout objects. But before ES6, JavaScript did not have a data structure for dictionaries (ES6 brought Maps). Therefore, objects had to be used as dictionaries, which imposed a signficant constraint: Dictionary keys had to be strings (symbols were also introduced with ES6).
We first look at features of objects that are related to dictionaries but also useful for fixed-layout objects. This section concludes with tips for actually using objects as dictionaries. (Spoiler: If possible, it’s better to use Maps.)
So far, we have always used fixed-layout objects. Property keys were fixed tokens that had to be valid identifiers and internally became strings:
const obj = {
mustBeAnIdentifier: 123,
;
}
// Get property
.equal(obj.mustBeAnIdentifier, 123);
assert
// Set property
.mustBeAnIdentifier = 'abc';
obj.equal(obj.mustBeAnIdentifier, 'abc'); assert
As a next step, we’ll go beyond this limitation for property keys: In this subsection, we’ll use arbitrary fixed strings as keys. In the next subsection, we’ll dynamically compute keys.
Two syntaxes enable us to use arbitrary strings as property keys.
First, when creating property keys via object literals, we can quote property keys (with single or double quotes):
const obj = {
'Can be any string!': 123,
; }
Second, when getting or setting properties, we can use square brackets with strings inside them:
// Get property
.equal(obj['Can be any string!'], 123);
assert
// Set property
'Can be any string!'] = 'abc';
obj[.equal(obj['Can be any string!'], 'abc'); assert
We can also use these syntaxes for methods:
const obj = {
'A nice method'() {
return 'Yes!';
,
};
}
.equal(obj['A nice method'](), 'Yes!'); assert
In the previous subsection, property keys were specified via fixed strings inside object literals. In this section we learn how to dynamically compute property keys. That enables us to use either arbitrary strings or symbols.
The syntax of dynamically computed property keys in object literals is inspired by dynamically accessing properties. That is, we can use square brackets to wrap expressions:
const obj = {
'Hello world!']: true,
['p'+'r'+'o'+'p']: 123,
[Symbol.toStringTag]: 'Goodbye', // (A)
[;
}
.equal(obj['Hello world!'], true);
assert.equal(obj.prop, 123);
assert.equal(obj[Symbol.toStringTag], 'Goodbye'); assert
The main use case for computed keys is having symbols as property keys (line A).
Note that the square brackets operator for getting and setting properties works with arbitrary expressions:
.equal(obj['p'+'r'+'o'+'p'], 123);
assert.equal(obj['==> prop'.slice(4)], 123); assert
Methods can have computed property keys, too:
const methodKey = Symbol();
const obj = {
[methodKey]() {return 'Yes!';
,
};
}
.equal(obj[methodKey](), 'Yes!'); assert
For the remainder of this chapter, we’ll mostly use fixed property keys again (because they are syntactically more convenient). But all features are also available for arbitrary strings and symbols.
Exercise: Non-destructively updating a property via spreading (computed key)
exercises/objects/update_property_test.mjs
in
operator: is there a property with a given key?The in
operator checks if an object has a property with a given key:
const obj = {
alpha: 'abc',
beta: false,
;
}
.equal('alpha' in obj, true);
assert.equal('beta' in obj, true);
assert.equal('unknownKey' in obj, false); assert
We can also use a truthiness check to determine if a property exists:
.equal(
assert.alpha ? 'exists' : 'does not exist',
obj'exists');
.equal(
assert.unknownKey ? 'exists' : 'does not exist',
obj'does not exist');
The previous checks work because obj.alpha
is truthy and because reading a missing property returns undefined
(which is falsy).
There is, however, one important caveat: truthiness checks fail if the property exists, but has a falsy value (undefined
, null
, false
, 0
, ""
, etc.):
.equal(
assert.beta ? 'exists' : 'does not exist',
obj'does not exist'); // should be: 'exists'
We can delete properties via the delete
operator:
const obj = {
myProp: 123,
;
}
.deepEqual(Object.keys(obj), ['myProp']);
assertdelete obj.myProp;
.deepEqual(Object.keys(obj), []); assert
Enumerability is an attribute of a property. Non-enumerable properties are ignored by some operations – for example, by Object.keys()
and when spreading properties. By default, most properties are enumerable. The next example shows how to change that and how it affects spreading.
const enumerableSymbolKey = Symbol('enumerableSymbolKey');
const nonEnumSymbolKey = Symbol('nonEnumSymbolKey');
// We create enumerable properties via an object literal
const obj = {
enumerableStringKey: 1,
: 2,
[enumerableSymbolKey]
}
// For non-enumerable properties, we need a more powerful tool
Object.defineProperties(obj, {
nonEnumStringKey: {
value: 3,
enumerable: false,
,
}: {
[nonEnumSymbolKey]value: 4,
enumerable: false,
,
};
})
// Non-enumerable properties are ignored by spreading:
.deepEqual(
assert...obj},
{
{enumerableStringKey: 1,
: 2,
[enumerableSymbolKey]
}; )
Object.defineProperties()
is explained later in this chapter. The next subsection shows how these operations are affected by enumerability:
Object.keys()
etc.enumerable | non-e. | string | symbol | |
---|---|---|---|---|
Object.keys() |
✔ |
✔ |
||
Object.getOwnPropertyNames() |
✔ |
✔ |
✔ |
|
Object.getOwnPropertySymbols() |
✔ |
✔ |
✔ |
|
Reflect.ownKeys() |
✔ |
✔ |
✔ |
✔ |
Each of the methods in tbl. 19 returns an Array with the own property keys of the parameter. In the names of the methods, we can see that the following distinction is made:
To demonstrate the four operations, we revisit the example from the previous subsection:
const enumerableSymbolKey = Symbol('enumerableSymbolKey');
const nonEnumSymbolKey = Symbol('nonEnumSymbolKey');
const obj = {
enumerableStringKey: 1,
: 2,
[enumerableSymbolKey]
}Object.defineProperties(obj, {
nonEnumStringKey: {
value: 3,
enumerable: false,
,
}: {
[nonEnumSymbolKey]value: 4,
enumerable: false,
,
};
})
.deepEqual(
assertObject.keys(obj),
'enumerableStringKey']
[;
).deepEqual(
assertObject.getOwnPropertyNames(obj),
'enumerableStringKey', 'nonEnumStringKey']
[;
).deepEqual(
assertObject.getOwnPropertySymbols(obj),
, nonEnumSymbolKey]
[enumerableSymbolKey;
).deepEqual(
assertReflect.ownKeys(obj),
['enumerableStringKey', 'nonEnumStringKey',
, nonEnumSymbolKey,
enumerableSymbolKey
]; )
Object.values()
Object.values()
lists the values of all enumerable string-keyed properties of an object:
const firstName = Symbol('firstName');
const obj = {
: 'Jane',
[firstName]lastName: 'Doe',
;
}.deepEqual(
assertObject.values(obj),
'Doe']); [
Object.entries()
[ES2017]Object.entries()
lists all enumerable string-keyed properties as key-value pairs. Each pair is encoded as a two-element Array:
const firstName = Symbol('firstName');
const obj = {
: 'Jane',
[firstName]lastName: 'Doe',
;
}.deepEqual(
assertObject.entries(obj),
['lastName', 'Doe'],
[; ])
Object.entries()
The following function is a simplified version of Object.entries()
:
function entries(obj) {
return Object.keys(obj)
.map(key => [key, obj[key]]);
}
Exercise: Object.entries()
exercises/objects/find_key_test.mjs
Own (non-inherited) properties of objects are always listed in the following order:
The following example demonstrates how property keys are sorted according to these rules:
> Object.keys({b:0,a:0, 10:0,2:0})[ '2', '10', 'b', 'a' ]
The order of properties
The ECMAScript specification describes in more detail how properties are ordered.
Object.fromEntries()
[ES2019]Given an iterable over [key, value] pairs, Object.fromEntries()
creates an object:
const symbolKey = Symbol('symbolKey');
.deepEqual(
assertObject.fromEntries(
['stringKey', 1],
[, 2],
[symbolKey
],
)
{stringKey: 1,
: 2,
[symbolKey]
}; )
Object.fromEntries()
does the opposite of Object.entries()
. However, while Object.entries()
ignores symbol-keyed properties, Object.fromEntries()
doesn’t (see previous example).
To demonstrate both, we’ll use them to implement two tool functions from the library Underscore in the next subsubsections.
pick()
The Underscore function pick()
has the following signature:
pick(object, ...keys)
It returns a copy of object
that has only those properties whose keys are mentioned in the trailing arguments:
const address = {
street: 'Evergreen Terrace',
number: '742',
city: 'Springfield',
state: 'NT',
zip: '49007',
;
}.deepEqual(
assertpick(address, 'street', 'number'),
{street: 'Evergreen Terrace',
number: '742',
}; )
We can implement pick()
as follows:
function pick(object, ...keys) {
const filteredEntries = Object.entries(object)
.filter(([key, _value]) => keys.includes(key));
return Object.fromEntries(filteredEntries);
}
invert()
The Underscore function invert()
has the following signature:
invert(object)
It returns a copy of object
where the keys and values of all properties are swapped:
.deepEqual(
assertinvert({a: 1, b: 2, c: 3}),
1: 'a', 2: 'b', 3: 'c'}
{; )
We can implement invert()
like this:
function invert(object) {
const reversedEntries = Object.entries(object)
.map(([key, value]) => [value, key]);
return Object.fromEntries(reversedEntries);
}
Object.fromEntries()
The following function is a simplified version of Object.fromEntries()
:
function fromEntries(iterable) {
const result = {};
for (const [key, value] of iterable) {
let coercedKey;
if (typeof key === 'string' || typeof key === 'symbol') {
= key;
coercedKey else {
} = String(key);
coercedKey
}= value;
result[coercedKey]
}return result;
}
Exercise: Using Object.entries()
and Object.fromEntries()
exercises/objects/omit_properties_test.mjs
If we use plain objects (created via object literals) as dictionaries, we have to look out for two pitfalls.
The first pitfall is that the in
operator also finds inherited properties:
const dict = {};
.equal('toString' in dict, true); assert
We want dict
to be treated as empty, but the in
operator detects the properties it inherits from its prototype, Object.prototype
.
The second pitfall is that we can’t use the property key __proto__
because it has special powers (it sets the prototype of the object):
const dict = {};
'__proto__'] = 123;
dict[// No property was added to dict:
.deepEqual(Object.keys(dict), []); assert
So how do we avoid the two pitfalls?
The following code demonstrates using prototype-less objects as dictionaries:
const dict = Object.create(null); // prototype is `null`
.equal('toString' in dict, false); // (A)
assert
'__proto__'] = 123;
dict[.deepEqual(Object.keys(dict), ['__proto__']); assert
We avoided both pitfalls:
__proto__
is implemented via Object.prototype
. That means that it is switched off if Object.prototype
is not in the prototype chain.Exercise: Using an object as a dictionary
exercises/objects/simple_dict_test.mjs
Just as objects are composed of properties, properties are composed of attributes. The value of a property is only one of several attributes. Others include:
writable
: Is it possible to change the value of the property?enumerable
: Is the property considered by Object.keys()
, spreading, etc.?When we are using one of the operations for handling property attributes, attributes are specified via property descriptors: objects where each property represents one attribute. For example, this is how we read the attributes of a property obj.myProp
:
const obj = { myProp: 123 };
.deepEqual(
assertObject.getOwnPropertyDescriptor(obj, 'myProp'),
{value: 123,
writable: true,
enumerable: true,
configurable: true,
; })
And this is how we change the attributes of obj.myProp
:
.deepEqual(Object.keys(obj), ['myProp']);
assert
// Hide property `myProp` from Object.keys()
// by making it non-enumerable
Object.defineProperty(obj, 'myProp', {
enumerable: false,
;
})
.deepEqual(Object.keys(obj), []); assert
Further reading:
Object.freeze(obj)
makes obj
completely immutable: We can’t change properties, add properties, or change its prototype – for example:
const frozen = Object.freeze({ x: 2, y: 5 });
.throws(
assert=> { frozen.x = 7 },
()
{name: 'TypeError',
message: /^Cannot assign to read only property 'x'/,
; })
Under the hood, Object.freeze()
changes the attributes of properties (e.g., it makes them non-writable) and objects (e.g., it makes them non-extensible, meaning that no properties can be added anymore).
There is one caveat: Object.freeze(obj)
freezes shallowly. That is, only the properties of obj
are frozen but not objects stored in properties.
More information
For more information on freezing and other ways of locking down objects, see Deep JavaScript.
Prototypes are JavaScript’s only inheritance mechanism: Each object has a prototype that is either null
or an object. In the latter case, the object inherits all of the prototype’s properties.
In an object literal, we can set the prototype via the special property __proto__
:
const proto = {
protoProp: 'a',
;
}const obj = {
__proto__: proto,
objProp: 'b',
;
}
// obj inherits .protoProp:
.equal(obj.protoProp, 'a');
assert.equal('protoProp' in obj, true); assert
Given that a prototype object can have a prototype itself, we get a chain of objects – the so-called prototype chain. Inheritance gives us the impression that we are dealing with single objects, but we are actually dealing with chains of objects.
Fig. 9 shows what the prototype chain of obj
looks like.
Non-inherited properties are called own properties. obj
has one own property, .objProp
.
Some operations consider all properties (own and inherited) – for example, getting properties:
> const obj = { one: 1 };
> typeof obj.one // own'number'
> typeof obj.toString // inherited'function'
Other operations only consider own properties – for example, Object.keys()
:
> Object.keys(obj)[ 'one' ]
Read on for another operation that also only considers own properties: setting properties.
Given an object obj
with a chain of prototype objects, it makes sense that setting an own property of obj
only changes obj
. However, setting an inherited property via obj
also only changes obj
. It creates a new own property in obj
that overrides the inherited property. Let’s explore how that works with the following object:
const proto = {
protoProp: 'a',
;
}const obj = {
__proto__: proto,
objProp: 'b',
; }
In the next code snippet, we set the inherited property obj.protoProp
(line A). That “changes” it by creating an own property: When reading obj.protoProp
, the own property is found first and its value overrides the value of the inherited property.
// In the beginning, obj has one own property
.deepEqual(Object.keys(obj), ['objProp']);
assert
.protoProp = 'x'; // (A)
obj
// We created a new own property:
.deepEqual(Object.keys(obj), ['objProp', 'protoProp']);
assert
// The inherited property itself is unchanged:
.equal(proto.protoProp, 'a');
assert
// The own property overrides the inherited property:
.equal(obj.protoProp, 'x'); assert
The prototype chain of obj
is depicted in fig. 10.
Recommendations for __proto__
:
Don’t use __proto__
as a pseudo-property (a setter of all instances of Object
):
Object
).For more information on this feature see §29.8.7 “Object.prototype.__proto__
(accessor)”.
Using __proto__
in object literals to set prototypes is different: It’s a feature of object literals that has no pitfalls.
The recommended ways of getting and setting prototypes are:
Getting the prototype of an object:
Object.getPrototypeOf(obj: Object) : Object
The best time to set the prototype of an object is when we are creating it. We can do so via __proto__
in an object literal or via:
Object.create(proto: Object) : Object
If we have to, we can use Object.setPrototypeOf()
to change the prototype of an existing object. But that may affect performance negatively.
This is how these features are used:
const proto1 = {};
const proto2a = {};
const proto2b = {};
const obj1 = {
__proto__: proto1,
a: 1,
b: 2,
;
}.equal(Object.getPrototypeOf(obj1), proto1);
assert
const obj2 = Object.create(
,
proto2a
{a: {
value: 1,
writable: true,
enumerable: true,
configurable: true,
,
}b: {
value: 2,
writable: true,
enumerable: true,
configurable: true,
,
}
};
).equal(Object.getPrototypeOf(obj2), proto2a);
assert
Object.setPrototypeOf(obj2, proto2b);
.equal(Object.getPrototypeOf(obj2), proto2b); assert
So far, “proto
is a prototype of obj
” always meant “proto
is a direct prototype of obj
”. But it can also be used more loosely and mean that proto
is in the prototype chain of obj
. That looser relationship can be checked via .isPrototypeOf()
:
For example:
const a = {};
const b = {__proto__: a};
const c = {__proto__: b};
.equal(a.isPrototypeOf(b), true);
assert.equal(a.isPrototypeOf(c), true);
assert
.equal(c.isPrototypeOf(a), false);
assert.equal(a.isPrototypeOf(a), false); assert
For more information on this method see §29.8.5 “Object.prototype.isPrototypeOf()
”.
Object.hasOwn()
: Is a given property own (non-inherited)? [ES2022]The in
operator (line A) checks if an object has a given property. In contrast, Object.hasOwn()
(lines B and C) checks if a property is own.
const proto = {
protoProp: 'protoProp',
;
}const obj = {
__proto__: proto,
objProp: 'objProp',
}.equal('protoProp' in obj, true); // (A)
assert.equal(Object.hasOwn(obj, 'protoProp'), false); // (B)
assert.equal(Object.hasOwn(proto, 'protoProp'), true); // (C) assert
Alternative before ES2022: .hasOwnProperty()
Before ES2022, we can use another feature: §29.8.8 “Object.prototype.hasOwnProperty()
”. This feature has pitfalls, but the referenced section explains how to work around them.
Consider the following code:
const jane = {
firstName: 'Jane',
describe() {
return 'Person named '+this.firstName;
,
};
}const tarzan = {
firstName: 'Tarzan',
describe() {
return 'Person named '+this.firstName;
,
};
}
.equal(jane.describe(), 'Person named Jane');
assert.equal(tarzan.describe(), 'Person named Tarzan'); assert
We have two objects that are very similar. Both have two properties whose names are .firstName
and .describe
. Additionally, method .describe()
is the same. How can we avoid duplicating that method?
We can move it to an object PersonProto
and make that object a prototype of both jane
and tarzan
:
const PersonProto = {
describe() {
return 'Person named ' + this.firstName;
,
};
}const jane = {
__proto__: PersonProto,
firstName: 'Jane',
;
}const tarzan = {
__proto__: PersonProto,
firstName: 'Tarzan',
; }
The name of the prototype reflects that both jane
and tarzan
are persons.
Fig. 11 illustrates how the three objects are connected: The objects at the bottom now contain the properties that are specific to jane
and tarzan
. The object at the top contains the properties that are shared between them.
When we make the method call jane.describe()
, this
points to the receiver of that method call, jane
(in the bottom-left corner of the diagram). That’s why the method still works. tarzan.describe()
works similarly.
.equal(jane.describe(), 'Person named Jane');
assert.equal(tarzan.describe(), 'Person named Tarzan'); assert
Looking ahead to the next chapter on classes – this is how classes are organized internally:
§29.3 “The internals of classes” explains this in more detail.
In principle, objects are unordered. The main reason for ordering properties is so that operations that list entries, keys, or values are deterministic. That helps, e.g., with testing.
Quiz
See quiz app.