Native Implementation of getElementsByClassName

DOM provides a method named getElementById (), which returns

DOM provides a method named getElementById (). This method returns an object, which is the element node corresponding to the parameter id. In addition, the getElementByTagName () method returns an array of objects, each of which corresponds to an element with a given tag in the document. The parameter of this method is the name of the html Tag. Now let's consider a question: can we get this object through the class name of the label? The following is the program implementation of this conjecture (supporting multiple class queries and querying within a certain range ):

/** Obtain the ID of the Element Set * @ param fatherId parent element based on the element clsssName, the default value is the document * @ tagName sub-element's tag name * @ className A className string separated by Space */function getElementsByClassName (fatherId, tagName, className) {node = fatherId & document. getElementById (fatherId) | document; tagName = tagName | "*"; className = className. split (""); var classNameLength = className. length; for (var I = 0, j = classNameLength; I
     
  
Okay. Let's test:
    
  
    
  
window.onload = function(){alert(getElementsByClassName(document,"div","aaa ccc").length);//2alert(getElementsByClassName("container","div","aaa ccc").length);//1alert(getElementsByClassName("container","span","aaa zzz").length);//1}
        
  
The result is correct.
    
  
Some people may ask, the native method call efficiency is the highest, and many browsers have already implemented the getElementsByClassName method. Why didn't we call the native method before calling the custom method?
        
  
Yes, the native efficiency is very high. It supports queries with multiple class conditions, but the biggest problem is that it does not support getElementsByClassName ("container", "div ", "aaa ccc"), which is used to find the specified element as the specified class in the specified tag. Therefore, native method calls are discarded here.
        
  
In the code, you will see that I have cached the length of the array to improve efficiency. In fact, there is a very hidden problem here, that is, the access length attribute of the array is very different from the access length attribute of the HtmlCollection. In an array, length is a common attribute and no additional operations are performed during access. To see HTMLCollection, we often use HTMLCollection as an array, but in fact, it is an object that automatically changes according to the DOM structure. Each time you access the attributes of an HTMLCollection object, it will perform a complete match on all the nodes in the DOM. That is to say, each time you access the length of the HtmlCollection object, the set object will be updated, which consumes a lot of performance. Therefore, we recommend that you cache the length of this HtmlCollection loop operation.
Episode
  
This is about the efficiency comparison between the ways to put elements in the array. Let's take a look at the Code:
  
  
// Method 1 var arr = []; var start = new Date (); for (var I = 0; I <100000; I ++) {arr. push (I) ;}// method 2 var arr = []; var start = new Date (); for (var I = 0; I <100000; I ++) {arr [arr. length] = I ;}
    
  
Let's guess, which one is more efficient! After testing, the efficiency of the second method is higher than that of the first method. Well, let's not talk about it much. This function is simple and practical. I also wrote comments on the code, so there should be no problem.
  
This article is available at http://www.nowamagic.net/librarys/veda/detail/195.