6 ms·
Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes
- geuis 3y agoThis 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".
- thex10 3y agoYeah, I’ve too noticed how hard it is to find any web development guidance involving direct DOM manipulation now! I was recently refactoring some code and wondering whether to use a (JS) class… The search results were mostly about React Class Components. And I was contemplating building a reusable component… results from the past decade were split between React Components and Web components. (In retrospect I should’ve tried DDG or something not connected to my search history lol). Anyway where are the vanilla JS/TS DOM manipulators blogging these days? I guess here is one, thankful for the post :)
- account-5 3y agohttps://gomakethings.com/ https://gomakethings.com/
- globalise83 3y agoNice! 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.
- beebeepka 3y agoSame applies to Set, too. You can store an object, or instance, then use "has" to check for it.
- akira2501 3y agoWhy not just use the 'dataset' property of the element itself? Then you can use querySelectorAll to find your selected rows automatically: node.querySelectorAll('tr[data-selected="true"]'); In other words.. "use the DOM to handle the DOM."
- nirvdrum 3y agoThat'd work for this specific case, but I think that was just a simplified example. A Map can store a value of any type, while the dataset property will always be a string. If you're only working with strings, it's a great option since you don't need to maintain a side data structure at all. But, serializing and deserializing arbitrary objects would be expensive.
- ZachSaucier 3y agoCouldn't you do elementReference.foo = whateverTypeYouWant? No need to restrict things to just the data attribute. This wouldn't work if you need to know the order of the properties.
- SSchick 3y agoThis generally doesn’t play nice with TS code bases and is generally considered an anti-pattern since there’s chances for collisions etc , you might get away using a unique symbol index but it’s still not good design.
- megous 3y agoChances for collisions are pretty much nil if you use some prefix standard will never use, like $. el.$my_data = ... And in practice it works just fine.
- rcfox 3y agoI'm not sure about DOM elements, but tacking random new properties onto Javascript objects can cause them to become deoptimized by the runtime.
- rektide 3y agoI need to read & consider this more, but my word, putting data in the DOM is so divine, is so the web way. See, HTML is the Web, https://www.petelambert.com/journal/html-is-the-web https://www.petelambert.com/journal/html-is-the-web
- incrudible 3y agoNot for me. The DOM is virtually always a poor fit for your view model. You will need to abstract it to stay sane, sooner or later. Manipulating DOM is slow and fraught with performance cliffs. In my opinion, DOM nodes should be disposable. A means to display data through the browser, not more. I avoid storing custom data on them, I avoid association like in the blog post. 98% of the time, you just want a simple transform from domain data into DOM nodes, for display. You really don't want to care which DOM nodes. This is how React works, and the reason why it is successful. Granted, once you get into the hundreds of elements updated at interactive rates, you may have to mess with the DOM directly, because you can't trust React to be smart about it. That's still just a consequence of DOM being terribly inefficient for historical reasons.
- kevincox 3y agoI 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. I think MDN has a good comparison: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map#objects_vs._maps https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... 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. class StringMap extends Map { toJSON() { return Object.fromEntries(this); } }
- panzerboiler 3y agoThat fix is not really a fix. The thing being broken for general serialization is JSON.
- Kiro 3y agoAnd how do deserialize it back to a StringMap without manually doing so? Being able to run a JSON.stringify and then JSON.parse on your state tree seamlessly is important imo.
- programmarchy 3y agoI’ve been using io-ts for this and been very happy with it. [1] It’s similar to Swift’s Coding protocol in case you’re familiar. [1] https://gcanti.github.io/io-ts/ https://gcanti.github.io/io-ts/
- taeric 3y agoI'd say the big downside is that they don't support the general looking accessor that I'd wager way way way too many people will accidentally use. Myself definitely being one of them. Would have been better if they didn't "seem" to work with the wrong syntax, at least. But, alas, here we are.
- kevincox 3y agoI'm typically using TypeScript so that is more or less a non-issue. But even then it seems like an easy thing to get used to.
- JoeSloth 3y agoThis 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.
- eviks 3y agoWhy did they not make the map assigning syntax as convenient as with objects, instead going for the clunky get/set?
- panzerboiler 3y agoBecause a Map is an Object. It has properties and methods. The only way to provide a safe and clean namespace for your keys is to provide an explicit API. It also supports keys that can be not only strings or symbols.
- beebeepka 3y agoSeveral things such as standard way for adding, removing and checking for keys, built-in size property, extensibility. You think "key in object" is better than "maaaaap.has(key)"? I don't because it's unpredictable and prone to exceptions. Give them a try. It's not a complete replacement for regular old objects