If I have a Map
in JavaScript, e.g
const myMap = new Map()
myMap.set(0, 'zero')
myMap.set(1, 'one')
Then both of these two seem to be valid to iterate through the key-value pairs (and many other options which I am currently not interested in):
// with .entries()
for (const [key, value] of myMap.entries()) {
//
}
// without
for (const [key, value] of myMap) {
//
}
Is there any edge case where they do not do the same?
CodePudding user response:
Is there any edge case where they do not do the same?
No. The iterator object you get from entries
is exactly the same one provided by the map itself. In fact, someMap[Symbol.iterator]
(the function called when you ask an object for its iterator) is literally the exact same function as someMap.entries
:
const someMap = new Map();
console.log(someMap[Symbol.iterator] === someMap.entries);
In the spec:
Map.prototype.entries
Map.prototype[@@iterator]
(@@iterator
isSymbol.iterator
) — which literally just points toentries
CodePudding user response:
Both do exactly the same by default.
When for...of
is used with a value as for (const item of collection)
then the well-known symbol @@iterator
is used to find what the values would be.
For Map
objects, @@iterator
will return .entries()
. It's exactly like calling the method because it is:
const map = new Map();
console.log(map[Symbol.iterator] === map.entries);
Therefore, both loops will do the same.
Small caveat: that is by default. If the @@iterator
symbol is overriden, then there can be different results:
const myMap = new Map()
myMap.set(0, 'zero')
myMap.set(1, 'one')
myMap[Symbol.iterator] = function* () {
const entries = this.entries();
for (const [key, value] of entries)
yield [key, value.toUpperCase()]; //transform the value
}
// with .entries()
for (const [key, value] of myMap.entries()) {
console.log("with .entries()", key, value)
}
// without
for (const [key, value] of myMap) {
console.log("without", key, value)
}
However, that is exceptionally unusual to happen. And if it does then it is likely that whoever supplied the map might actually want a different iteration logic.