Bits of .NET

⚡ The Set That’s Supposed to Remove Duplicates and Somehow Didn’t

A JavaScript `Set` is built specifically to hold only unique values – but when it’s populated with objects rather than primitives, two items that look completely identical when logged to the console can both end up in the Set, because `Set` uses the exact same reference equality as `===` : two separately-created objects with identical properties are still two different references, and the Set treats them as two different values.

🔎 The Problem

const uniqueUsers = new Set();

uniqueUsers.add({ id: 42, name: "Ayşe" });
uniqueUsers.add({ id: 42, name: "Ayşe" });   // Looks identical...

console.log(uniqueUsers.size);   // 2, not 1

// Set.has() and the uniqueness Set provides are both based on the SAME
// object identity used by ===. Two object literals with identical
// properties are still two separate objects in memory - Set has no
// built-in concept of "these represent the same data," only "is this
// literally the same reference I'"'"'ve already seen."

✅ Fix: Dedupe by a Key, Not by the Object Itself

• For objects that have a natural unique identifier (an `id` field, as here), build a `Map` keyed by that identifier instead of a `Set` of the objects themselves – `new Map(users.map(u => [u.id, u]))` naturally keeps only the last occurrence for each id, which is usually exactly the deduplication behavior actually wanted.
• Where no natural key exists, deduplicating by a stable serialized form (`JSON.stringify` of a normalized, key-sorted version of each object) as the Set’s actual stored value works, though it’s worth being careful that two objects considered semantically equal always serialize to an identical string – key order matters to `JSON.stringify` unless it’s explicitly normalized first.
• A small deep-equality-aware dedupe helper (using Lodash’s `_.uniqBy`, or a hand-rolled comparison for simple cases) is often clearer to read than either of the above once the number of fields that matter for comparison grows past one or two.

⚠️ Why This Is an Easy Assumption to Make

• `Set` correctly deduplicates primitives (numbers, strings, booleans) by VALUE, which is the far more common use case people reach for `Set` with in the first place – the surprising, reference-based behavior only shows up once objects specifically are added, which can be long after a developer has already formed the (correct, for primitives) mental model that Set just “removes duplicates.”
• This is worth double-checking anywhere data comes from an API and might contain duplicate records that are structurally identical but were fetched or constructed as separate objects – a naive `new Set(apiResults)` silently does nothing useful in that exact case.