Map and Set: when a plain object is the wrong tool

The lookup table you built in lesson 3 is a good tool, and for string ids it is often the right one. But it has three limits you will run into, and once you know them the choice becomes easy rather than a matter of taste.

First, keys are always text. You cannot key by a number and get a number back, and you certainly cannot key by an object — every object flattens to the same text "[object Object]" and they all collide into a single entry.

Second, the object already answers to inherited names such as toString, so keys that come from data need Object.hasOwn every single time you touch them, and forgetting once is a bug.

Third, there is no straightforward count. You write Object.keys(table).length, which builds a whole array of names just to measure it, and you do it every time you want the number.

A Map is the answer to all three. It is a purpose-built collection of key-value pairs where the keys keep their type, nothing is inherited, and the count is a property.

You create one with new Map(), optionally handing it an array of [key, value] pairs to start from. Then there are five operations and you will use all of them: set(key, value) stores, get(key) reads, has(key) asks whether the key is present, delete(key) removes, and size tells you how many pairs there are.

size is a property, not a method — map.size with no brackets. Everything else is a method with brackets. Getting this the wrong way round is the single most common Map typo.

get returns undefined for a key that was never set, exactly like a plain object. But because a Map has no inherited keys, undefined here really does mean absent, and has(key) tells you the difference between a key you never set and a key you set to undefined.

A Map remembers the order its keys were first inserted, and every way of walking it — for...of, forEach, spreading it into an array — follows that order. That is a guarantee you do not get from a plain object, where numeric-looking keys are reordered ahead of the rest.

In a Map, the key 1 and the key "1" are two different keys, because a Map compares keys by value and type rather than converting them to text. So does an object used as a key: two different objects are two different keys, even if they hold identical properties, because they are different objects.

The comparison rule has a name, SameValueZero, and it matters in exactly one place: NaN. Ordinary comparison says NaN is not equal to itself, but SameValueZero treats NaN as equal to NaN, so you can store something under a NaN key and get it back. It also treats 0 and -0 as the same key.

Being able to key by an object sounds exotic until the first time you need it — attaching extra information to things you did not create, caching a result per record, marking which items you have already handled. All of those are Map jobs and none of them can be done with a plain object.

If a Map is a phone book, a Set is a guest list. It answers exactly one question — is this on the list? — and it holds each entry once no matter how many times you add it.

new Set(someArray) is the shortest deduplicate in the language: it drops every repeat and keeps the first occurrence's position. Spreading it back with [...set] gives you an array again, in that order.

The operations are add(value), has(value), delete(value) and size. Note that it is add here and set there; a Set has no keys and values to pair up, only members.

Reach for a Set whenever you catch yourself writing array.includes(x) inside a loop. includes walks the array every time, exactly like find did in the last lesson; has does not.

JSON.stringify(map) produces {} — an empty object — no matter what is in it. Nothing throws and nothing warns you. The same is true of a Set.

The reason is not a bug: JSON.stringify serialises an object's own enumerable properties, and a Map keeps its contents somewhere else entirely, not in ordinary properties. There is nothing for stringify to find.

So a Map is the wrong choice for anything you are about to save or send, unless you convert it first. Object.fromEntries(map) turns it into a plain object when the keys are strings, and [...map] turns it into an array of [key, value] pairs which survives JSON and can be handed straight back to new Map() on the other side. Choose the array form when the keys are not strings, because the object form would flatten them.

This is the clearest example in the whole module of the general rule: the shape you compute with and the shape you store are allowed to be different, and converting between them deliberately is better than picking one shape that is mediocre at both.

Use a plain object when the keys are a small, known set of names that you type yourself — a settings record, an options bag, anything you will serialise. Use a Map when the keys come from data, when there are many of them, when they are not strings, when you add and remove often, or when insertion order matters.

Use a Set instead of an array whenever the only question you ask is whether something is present, and duplicates are meaningless.

None of these are performance micro-decisions. They are about which mistakes the shape makes impossible. A Map cannot collide with toString; a Set cannot hold a duplicate. Choosing the container that rules out your bug is cheaper than remembering not to write it.