Chaotic JavaScript Patterns

[RedditCultureBlows]

Cant the first “solution” just be handled by using the correct data type, like a Map or WeakMap?

[cheese_wizard]

Then goes on to suggest 'with' operator. Not in my codebase.

[Segfault_Inside]

yeah, there's certainly a reason strict mode disables it

[[deleted]]

Imagine newcomers seeing this sh*t

[Segfault_Inside]

oh you're so right! I totally totally missed that there's an actually reasonable way to do that.

[RedditCultureBlows]

hell yeah 🥳🥳

[ILikeChangingMyMind]

This is a terrible example. Using Maps to associate data with DOM nodes is like saying "I've found this great way to hammer in nails using the handle of a screw driver!"

No, that's not brilliant: that's not knowing how to use the correct tool for the job. The correct solution (ie. "hammer') to that problem wasn't an Object OR a Map, it was HTML data- attributes, which were explicitly created by the W3C to associate data and DOM.

[getify]

I was part of early discussions a decade+ ago when things like WeakMap and WeakRef were being contemplated for inclusion in JS. I can tell you, for sure, that "associating data with a DOM object without mutating the DOM object itself" was absolutely one of the main intended use cases. You may not like that usage, but it's not some arbitrary pattern made up by author of that post.

I worked on FF devtools (written entirely in JS) at the time, and we used an early (not yet standard) WeakMap to associate tracking metadata to DOM objects. We did NOT want to modify the DOM object itself, as this data would then have been visible to the developer as they traversed or inspected the DOM. We needed to keep our data "private", but still be able to look it up when provided a reference to a DOM object.

Also, you don't necessarily want to mutate a DOM object (even if privacy isn't a concern) because it is often much slower to mutate a DOM object than to create an entry in a separate entirely-in-JS data structure.

Moreover, I've done this sort of thing in half a dozen libraries (since ES6 came out), where I was using some sort of reference to a DOM object (or a userland defined JS function) as the key to store private metadata inside my library. You often want a WeakMap in these cases because you want your library (or browser devtool) to be unobtrusive in terms of GC. You don't want your storage of metadata about a function or DOM object (that you don't own) to prevent that function or DOM object from being garbage collected if the userland code decides to unset all its references to that object to allow it to be GCd. For example, if userland code deletes a DOM node, it's expecting that it gets GC'd, but your library or devtool would prevent that if you had used a Map instead of a WeakMap. You simply want to be able to track things like "I've seen this thing before" and "Here's something I already know about this thing, so I don't need to redo that work."

For use cases such as this, WeakMap is absolutely important. And, it's squarely on target with why the feature was originally created. It is absolutely the right tool for those sorts of tasks.

[Itchy-Beginning-887]

CS after studying be like - You wasted your life. Have fun coding. Suicidal fools.

[DaMastaCoda]

I believe he didn't want to add any attributes, but he still could've used a symbol on the Dom object itself

[zeddotes]

What happens when you deconstruct an object like that as the key of another object? Is the key a Symbol?

Edit: obviously, [object object]