Map vs Plain Object

## The rule behind the output A property key in JavaScript can only be a string or a symbol. Nothing else. When you write `o[k]`, the engine takes `k` and, unless it is already a symbol, converts it to a string before touching the object. So a numeric key, a boolean, `null`, or a whole object all become string property names. ```js const o = {}; o[1] = 'a'; o['1'] = 'b'; console.log(Object.keys(o)); // [ '1' ] — one property, value 'b' ``` A `Map` is a different kind of collection. Its entries are held in internal storage, not as properties, and the key is stored as the value you handed over — number stays number, object stays that object. Lookups compare keys by value identity rather than by string name, so nothing collapses together. ```js const m = new Map(); m.set(1, 'a'); m.set('1', 'b'); console.log(m.size); // 2 console.log(m.get(1)); // 'a' ``` Hence `1 2`. ## What happens with object keys Using an object as a plain-object key is the more dramatic version of the same trap. Converting an ordinary object to a string yields `'[object Object]'`, so every distinct object you use as a key lands on that single property: ```js const a = { id: 1 }; const b = { id: 2 }; const o = {}; o[a] = 'first'; o[b] = 'second'; console.log(Object.keys(o)); // [ '[object Object]' ] console.log(o[a]); // 'second' — b overwrote a ``` With a `Map`, `a` and `b` are two different keys, because object keys are matched by reference — the very same object, not one that merely looks alike: ```js const m = new Map([[a, 'first'], [b, 'second']]); console.log(m.size); // 2 console.log(m.get(a)); // 'first' console.log(m.get({ id: 1 })); // undefined — a different object ``` That last line is the counterpart trap: a `Map` will not find an entry from a structurally equal but freshly constructed key. If you want lookup by content, derive a primitive key yourself (an id, a canonical string) and use that. ## Symbols are the exception Symbols are legal property keys and are not stringified, so `o[Symbol('x')]` really does create a symbol-keyed property. But symbol keys do not show up in `Object.keys`, `JSON.stringify`, or a `for...in` loop, which is a separate reason not to rely on them for dictionary storage. ## Where this bites in real code The common bug is an id-keyed lookup built from mixed sources. Ids that arrive as numbers from one code path and as strings from another silently unify inside a plain object, so a cache appears to work until two "different" ids collide — or until you read the keys back and discover every one of them is now a string: ```js const byId = {}; byId[42] = { name: 'Ada' }; console.log(typeof Object.keys(byId)[0]); // 'string' ``` Any code that later compares `Object.keys(byId)[0] === 42` fails, because the key came back as `'42'`. With a `Map` keyed by the number 42, `[...byId.keys()][0] === 42` holds, since the key was never converted. ## How to avoid it Three practical moves. First, normalise: pick one key type and coerce at the boundary (`String(id)` or `Number(id)`) so mixed sources cannot diverge. Second, if the keys are genuinely not strings — objects, functions, numbers you want to stay numbers — use a `Map`, which is exactly the collection for that. Third, when you must use a plain object, remember that its keys are a string namespace: reading them back gives strings, and anything you can turn into the same string is the same slot. The interviewer's real target here is whether you know that object property keys are a *string* namespace, not an arbitrary-value one, and that `Map` was added to the language precisely to lift that restriction.