Live data from Hacker News

Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

macarthur.me

21–30 of 30 posts

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#21
post #7

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. I think MDN has a good comparison: 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 `toJS…

That fix is not really a fix. The thing being broken for general serialization is JSON.

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#22
post #12
post #7

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. I think MDN has a good comparison: 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 `toJS…

What is a "mapping" structure?

Key value, dictionary, ...

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#23
post #18

Why did they not make the map assigning syntax as convenient as with objects, instead going for the clunky get/set?

Several 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

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#24
post #7

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. I think MDN has a good comparison: 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 `toJS…

And 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.

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#25
post #6

I 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

Not 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.

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#26
post #24
post #7

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. I think MDN has a good comparison: 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 `toJS…

And 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.

I’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/

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#27
post #14

Earlier quoted context omitted.

Couldn'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.

This 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.

Chances 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.

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#28
post #16
post #14

Earlier quoted context omitted.

This 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.

I'm not sure about DOM elements, but tacking random new properties onto Javascript objects can cause them to become deoptimized by the runtime.

Any reference for this?

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#29
post #16

Earlier quoted context omitted.

I'm not sure about DOM elements, but tacking random new properties onto Javascript objects can cause them to become deoptimized by the runtime.

Any reference for this?

I found [1] to be a pretty good summary of the key concepts that support the claim. The article, unfortunately, doesn't come right out and say it. But, it talks about how object shapes (a common JS object model) can be used as guards for inline caches (IC) to generate efficient machine code for property access. If you add a new property, you change the shape, which causes the cache guard to fail. That leads to deoptimization since the assumptions made about the call site when the code was compiled no longer hold. That call site is now either polymorphic or megamorphic, depending on the type of IC used and its level of polymorphism.

[1] -- https://mathiasbynens.be/notes/shapes-ics

Re: Why I Like Using Maps (and WeakMaps) for Handling DOM Nodes

#30
post #16

Earlier quoted context omitted.

I'm not sure about DOM elements, but tacking random new properties onto Javascript objects can cause them to become deoptimized by the runtime.

Any reference for this?

https://v8.dev/blog/fast-properties

https://v8.dev/docs/hidden-classes

Post reply on HN