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 DOM element.
An example can be seen here. If you look down at the DocumentFragment section you'll see this:
oFrag = document.createDocumentFragment();
for (var i = 0, imax = aElms.length; i < imax; i++) {
oFrag.appendChild(aElms[i]);
}
o.innerHTML = '';
o.appendChild(oFrag.cloneNode(true));
Why does "oFrag" get cloned instead of just appending it? Another blog post doesn't use "cloneNode" (as a comparison).
Your first link refers to the blog post where the autor uses
document.getElementsByTagName
instead ofdocument.getElementById
, like in test case. If you want a multiple elements (namely: divs) to be given the samedocumentFragment
, you must clone it: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
withoutcloneNode
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'! ;)
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.
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
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 callingappendChild
. It's only for performance in this test.However, the following code (more similar to the
appendChild
test) would make more sense to me: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 :-)