I would argue that all "mapping" structures should use Map these days. Objects should be used only for record/struct data with a fixed set of programmer-named keys.<p>I think MDN has a good comparison: <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#objects_vs._maps" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...</a><p>The only real downside of maps is that they don't support JSON serialization. However you can fix this pretty easily by using a map with an overridden `toJSON` for serializable keys.<p><pre><code> class StringMap extends Map {
toJSON() {
return Object.fromEntries(this);
}
}</code></pre>
Why not just use the 'dataset' property of the element itself? Then you can use querySelectorAll to find your selected rows automatically:<p><pre><code> node.querySelectorAll('tr[data-selected="true"]');
</code></pre>
In other words.. "use the DOM to handle the DOM."
This might be one of the more interesting articles I've read in a few years that deal with low level direct DOM manipulation vs "yet another thing about React".
Nice! I have used Maps often for storing arbitrary key-value pairs, but until 5 minutes ago I didn't know you could use object references as keys. So this was a very good use of 5 mins.
I need to read & consider this more, but my word, putting data <i>in</i> the DOM is so divine, is so the web way. See, HTML is the Web, <a href="https://www.petelambert.com/journal/html-is-the-web" rel="nofollow">https://www.petelambert.com/journal/html-is-the-web</a>
This is great for some use cases, but in situations like a very large list mentioned in the article it’s likely that a real world app would be virtualizing the nodes.. which would make an id a more stable key than a dom node.