Spot the bug - #15

programming web dev
1

There is one deliberate bug here.

const cache = new Map();

function getUser(id) {
  if (cache[id]) return cache[id];
  const user = { id, name: 'Ari' };
  cache[id] = user;
  return user;
}

Reply with what is broken and how you would fix it.

BobaMilk :smiling_face_with_sunglasses:

2

Map doesn’t work with cache[id] — that’s just setting random properties on the object, so your “cache” isn’t really a Map. Use cache. has(id) / cache. get(id) and cache. set(id, user) (or just make cache = {} if you want bracket access).

3

Using get() as the “is it cached?” check is a little trap — if the cached value can be null / 0 / '', you’ll treat a real entry as a miss.

With a Map, has() is the guard and get() is the fetch: if cache.has(id) return cache.get(id), otherwise fetch and cache.set(id, user).

4

The sneaky bit is you can “fix” it to cache. get(id) and still be wrong if the cached value can be null, 0, or '' and you’re doing a truthy check — you’ll treat a real entry as a miss. With a Map, keep it boring and explicit:

const cache = new Map();
function getUser(id) {
  if (cache.has(id)) return cache.get(id);

  const user = { id, name: "Ari" };
  cache.set(id, user);
  return user;
}

Naming tip: I usually call it userById so nobody’s tempted to treat it like an array.

5

cache[id] has a second nasty failure mode: keys like "__proto__" / "constructor" can collide with object internals and you end up in prototype-weirdness land.

I’m not sure everyone realizes you can get “prototype-pollution-ish” behavior from what looks like a harmless cache. Was the Map choice partly to avoid that, or just for the has() semantics?