In a delegated list handler, why keep per-item state in a JavaScript Map captured by the handler's closure rather than storing it in data-* attributes on the elements?

## The shape of the pattern A delegated handler is a closure. You create it inside a function that also owns the container, and that scope can hold anything you want the handler to see later: ```js function createList(container) { const state = new Map(); // id -> real JS values container.addEventListener('click', (event) => { const row = event.target.closest('li[data-id]'); if (!row || !container.contains(row)) return; const item = state.get(row.dataset.id); item.done = !item.done; row.classList.toggle('done', item.done); }); return (id, item) => { state.set(id, item); /* ...render row... */ }; } ``` One listener, one state container, one id in the markup. The DOM holds the identity of the row; the closure holds what the row *is*. ## Why the closure is the better home **Types survive.** A `Map` value can be an object, a `Date`, a nested array, even a function. `data-*` storage flattens everything through string conversion: `el.dataset.count` is `"3"`, not `3`, so `dataset.count + 1` silently produces `"31"`. Anything structured has to be JSON round-tripped, which loses types that JSON has no representation for. **Identity survives.** If the same object also lives in the array you render from, the closure hands you *that* object — mutating it and re-rendering stays consistent. A serialised copy in an attribute is a second source of truth that will drift. **Privacy.** State in the closure is reachable only through the functions you return. State in the DOM is world-readable and world-writable: any other script, extension or stylesheet selector can read it and depend on it, which turns an implementation detail into an accidental contract. **Cost.** Reading and writing attributes touches the DOM; reading a `Map` does not. This rarely dominates, but it is free to avoid. ## What the DOM should still carry Not nothing — a stable id. The handler receives an element and needs to turn it into a state entry, so the element must identify itself. A `data-id` is the smallest possible bridge: a string that means "look me up". Also keep in the DOM whatever the *view* legitimately needs — classes reflecting state so CSS can style them, ARIA attributes conveying state to assistive technology. The rule is directional: state flows from the closure into the DOM as presentation, never the reverse. ## Keying and cleanup A `Map` keyed by id has one hazard: it does not know when a row disappears. Remove 10,000 rows over a session and you still hold 10,000 entries, which is a slow leak of your own making. Whatever code removes a row must delete its entry — put both in the same function so they cannot drift apart. The alternative is keying by the element itself in a `WeakMap`. Then discarding the element makes its entry unreachable and collectable with no bookkeeping. The trade is that you can no longer look state up by id — only by holding the element — and the entry does not survive a re-render that replaces the node. Use a `Map` keyed by id when rows are recreated from data; use a `WeakMap` keyed by node when the node is the identity and lives as long as the state should. ## When the DOM genuinely is the right place Be honest about the exceptions. Put a value in the markup when: - it is markup-rendered on the server and must be present before any script runs; - CSS needs it, via an attribute selector; - it *is* presentation — a label, an image source, a `disabled` flag; - an external consumer, such as a test selector or analytics attribute, is meant to read it. What does not belong there is the model: the object your code mutates, computes with, and re-renders from. ## The failure this prevents The usual bug goes like this. Someone stores `data-count="0"`, increments it with `el.dataset.count = el.dataset.count + 1`, and ships `"01"`. Someone else stores a serialised object and it drifts from the array the page renders from. Then a re-render rebuilds the row from data and every value written into the markup by the handler is silently gone. Keeping state in the closure removes all three failure modes at once, and the delegated handler already had the scope to do it.