Why Does Clonenode Need To Be Used When Appending A Documentfragment?

I've been looking at using documentFragments in a Backbone.js app and was wondering why I see examples where 'cloneNode' is used when appending the documentFragment to the parent D

Solution 1:

Your first link refers to the blog post where the autor uses document.getElementsByTagName instead of document.getElementById, like in test case. If you want a multiple elements (namely: divs) to be given the same documentFragment, you must clone it:

If child is a reference to an existing node in the document, appendChild moves it from its current position to the new position (i.e. there is no requirement to remove the node from its parent node before appending it to some other node).

This also means that a node can't be in two points of the document simultaneously. So if the node already has a parent, it is first removed, then appended at the new position.

via MDN

Most likely the author (or someone else) copy-pasted the code without taking this into consideration. Try it yourself - you can use appendChild without cloneNode and everything works fine.

Another possibility is that someone who created this test case on jsperf didn't get much how preparation code works and was worried that the very first test will empty aElms array and it won't work anymore. In fact preparation code is executed before each timed iteration, so there's no need to be worried about its contents.

The last thing may the performance concern. If you really want to test the real insertion, you need to clone the node. Otherwise, you'll test tree reattachment instead (see MDN link above).

Also please note that cloning destroys event listeners.

Happy fragmentin'! ;)

Solution 2:

If you append a documentFragment to an element, and you later clear the appended nodes from that element, your documentFragment will also be empty and cannot be reused anymore! Appending a clone of your documentFragment prevents this and allows multiple reuses of your documentFragment.

I assume the author of the jsperf snippet was testing for such a case.

Example: dropdowns with a parent-child relationship. Lets say you have a dropdown where you select a continent, and a second dropdown that lists all the countries in that continent. If you want to cache the created documentFragments with the option nodes after creation, using cloneNode is necessary. Imagine someone selects europe, then africa, then europe again: you can either recreate the entire documentfragment, of cache it.

I created a jsperf snippet to illustrate the performance difference of recreating the documentFragments vs caching and cloning the fragments:

http://jsperf.com/documentfragment-cache-vs-recreate

Solution 3:

I'm not exactly sure, but in the context of the link you provided (performance testing) the oFrag.cloneNode(true) might be a safeguard against reusing the elements already added in DOM in previous runs of the loop, which would result in way faster execution of the test.

I see no reason to use it in normal use cases of documentFragments.

Solution 4:

I don't think it's necessary. I guess it only was used to detach the aElms from being statically referenced, where they would've need to be removed from their former parents when calling appendChild. It's only for performance in this test.

However, the following code (more similar to the appendChild test) would make more sense to me:

var oFrag = document.createDocumentFragment();
for (var i = 0, imax = aElms.length; i < imax; i++)
    oFrag.appendChild(aElms[i].cloneNode(true));
// using it here:             ^^^^^^^^^^^^^^^^
o.appendChild(oFrag);

Though it might be slower than calling it only once on the whole fragment, where the node tree is recursed with native code.

Also check out http://jsperf.com/cloning-fragments :-)