Why I Like Utilizing Maps (and WeakMaps) for Dealing with DOM Nodes

We use numerous plain, previous objects to retailer key/worth knowledge in JavaScript, and so they’re nice at their job – clear and legible:

const particular person = {
	firstName: 'Alex', 
	lastName: 'MacArthur', 
	isACommunist: false
};

However while you begin coping with bigger entities whose properties are steadily being learn, modified, and added, it is turning into extra frequent to see folks attain for Maps as an alternative. And for good purpose: in sure conditions, there are multiple advantages a Map has over an object, significantly these wherein there are delicate efficiency issues or the place the order of insertion actually issues.

However as of late, I’ve realized what I particularly like to make use of them for: dealing with giant units of DOM nodes.

This thought got here up whereas studying a recent blog post from Caleb Porzio. In it, he is working with a desk composed of 10,000 desk rows, one in every of which may be “energetic.” To handle state as totally different rows are chosen, an object is used as a key/worth retailer. This is an annotated model of one in every of his iterations. I additionally added semicolons as a result of I’m not a barbarian.

import { ref, watchEffect } from 'vue';

let rowStates = {};
let activeRow;

doc.querySelectorAll('tr').forEach((row) => {
    
    rowStates[row.id] = ref(false);

    row.addEventListener('click on', () => {
        
        if (activeRow) rowStates[activeRow].worth = false;

        activeRow = row.id;

        rowStates[row.id].worth = true;
    });

    watchEffect(() => {
        
        if (rowStates[row.id].worth) {
            row.classList.add('energetic');
        } else {
            row.classList.take away('energetic');
        }
    });
});

That does the job simply effective (and it had nothing to do with the submit’s level, so zero shade is being thrown right here). However! It makes use of an object as a big hash-map-like desk, so the keys used to affiliate values should be a string, thereby requiring a singular ID (or different string worth) exist on every merchandise. That carries with it a little bit of added programmatic overhead to each generate and browse these values once they’re wanted.

As a substitute, a Map would permit us to use the HTML nodes as keys themselves. So, that snippet finally ends up trying like this:

import { ref, watchEffect } from 'vue';

- let rowStates = {};
+ let rowStates = new Map();
let activeRow;

doc.querySelectorAll('tr').forEach((row) => {
-	rowStates[row.id] = ref(false);
+   rowStates.set(row, ref(false));

    row.addEventListener('click on', () => {
-       if (activeRow) rowStates[activeRow].worth = false;
+       if (activeRow) rowStates.get(activeRow).worth = false;

        activeRow = row;

-       rowStates[row.id].worth = true;
+       rowStates.get(activeRow).worth = true;
    });

    watchEffect(() => {
-       if (rowStates[row.id].worth) {
+       if (rowStates.get(row).worth) {
            row.classList.add('energetic');
        } else {
            row.classList.take away('energetic');
        }
    });
});

The obvious profit right here is that I needn’t fear about distinctive IDs present on every row. The node references themselves – inherently distinctive – function the keys. Due to this, neither setting nor studying any attribute is critical. It is less complicated and extra resilient.

I’ve italicized “typically” as a result of, usually, the distinction is negligible. However while you’re working with bigger knowledge units, the operations are notably extra performant. It is even within the specification – Maps have to be in-built a means that preserves efficiency because the variety of gadgets continues to develop:

Maps have to be applied utilizing both hash tables or different mechanisms that, on common, present entry instances which might be sublinear on the variety of components within the assortment.

“Sublinear” simply implies that efficiency will not degrade at a proportionate charge to the scale of the Map. So, even huge Maps ought to stay pretty snappy.

However even on prime of that, once more, there is not any must mess with DOM attributes or performing a look-up by a string-like ID. Every key’s itself a reference, which suggests we are able to skip a step or two.

I did some rudimentary efficiency testing to verify all of this. First, sticking with Caleb’s state of affairs, I generated 10,000 <tr> components on a web page:

const desk = doc.createElement('desk');
doc.physique.append(desk);

const depend = 10_000;
for (let i = 0; i < depend; i++) {
  const merchandise = doc.createElement('tr');
  merchandise.id = i;
  merchandise.textContent = 'merchandise';
  desk.append(merchandise);
}

Subsequent, I arrange a template for measuring how lengthy it might take to loop over all of these rows and retailer some related state in both an object or Map. I am additionally operating that very same course of inside a for loop a bunch of instances, after which figuring out the typical period of time it took to jot down & learn.

const rows = doc.querySelectorAll('tr');
const instances = [];
const testMap = new Map();
const testObj = {};

for (let i = 0; i < 1000; i++) {
  const begin = efficiency.now();

  rows.forEach((row, index) => {
    
	
	

	
	
	
  });

  instances.push(efficiency.now() - begin);
}

const common = instances.scale back((acc, i) => acc + i, 0) / instances.size;

console.log(common);

I ran this check with a spread totally different row sizes.

Have in mind these outcomes would possible range fairly a bit in even barely totally different circumstances, however on the entire, they often met my expectations. When coping with comparatively small numbers of things, efficiency between a Map and object was comparable. However because the variety of gadgets elevated, the Map began to tug away. That sublinear change in efficiency began to shine.

There is a particular model of the Map interface that is designed to steward reminiscence a bit higher – a WeakMap. It does so by holding a “weak” reference to its keys, so if any of these object-keys not have a reference certain to it elsewhere, it is eligible for rubbish assortment. So, when the bottom line is not wanted, your entire entry is routinely axed from the WeakMap, clearing up much more reminiscence. It really works for DOM nodes too.

See Also

the following technology. Investing within the subsequent technology of committers. – James Governor’s Monkchips

To tinker with this, we’ll be utilizing the FinalizationRegistry, which triggers a callback each time a reference you are watching has been rubbish collected (I by no means anticipated to search out one thing like this useful, lol). We’ll begin with just a few record gadgets:

<ul>
  <li id="item1">first</li>
  <li id="item2">second</li>
  <li id="item3">third</li>
</ul>

Subsequent, we’ll stick these gadgets in a WeakMap, and register item2 to be watched by the registry. We’ll take away it, and each time it has been rubbish collected, the callback might be triggered and we’ll have the ability to see how the WeakMap has modified.

However… rubbish assortment is unpredictable and there is not any official approach to make it occur, so to encourage it, we’ll periodically generate a bunch of objects and persist them in reminiscence. This is your entire script:

(async () => {
	const listMap = new WeakMap();

	
	doc.querySelectorAll('li').forEach((node) => {
		listMap.set(node, node.id);
	});

	const registry = new FinalizationRegistry((heldValue) => {
		
		console.log('After assortment:', heldValue);
	});

	registry.register(doc.getElementById('item2'), listMap);
    
	console.log('Earlier than assortment:', listMap);

	
	doc.getElementById('item2').take away();

 	
 	const objs = [];
 	whereas (true) {
   		for (let i = 0; i < 100; i++) {
			objs.push(...new Array(100));
		}

		await new Promise((resolve) => setTimeout(resolve, 10));
	}
})();

Earlier than something occurs, the WeakMap holds three gadgets, as anticipated. However after the second merchandise is faraway from the DOM and rubbish assortment happens, it seems to be a little bit totally different:

Because the node reference not exists within the DOM, your entire entry was faraway from the WeakMap, liberating up a smidge extra reminiscence. It is a characteristic I recognize in serving to to maintain an atmosphere’s reminiscence only a bit tidier.

I like utilizing Maps for DOM nodes as a result of:

• The nodes themselves can be utilized as keys. I needn’t mess with setting or studying distinctive attributes on every node first.
• With giant numbers of objects, they’re (designed to be) extra performant.
• Utilizing a WeakMap with nodes as keys means entries might be routinely rubbish collected if a node is faraway from the DOM.

I am taken with listening to of different fascinating causes to make use of “newish” objects like Map and Set in real-life situations. When you’ve got ’em, share ’em!