JavaScript event loading and preloading

Generally speaking, it is enough. If you want to load multiple events, we can take the following methods:

But if we cannot write together due to some special needs? If the current area is for administrators, this part will be generated only when the user is an administrator when generating pages in the background. This part also uses some special scripts, so the above method will stop!

The page generated in this case has two code blocks, and it is obvious that the second one covers the first one. At this time, it is the loadEvent function that comes out.

It perfectly solves the problem of mutual coverage, and uses it as follows:

But the real problems are always so surprising and so tactful. Recently I wanted to put all the functions into a closure to avoid naming conflicts, such as the famous $DOM selector. JQuery, Prototype, and mootool all use it as selector names, and coexistence has become a serious problem.


However, such a famous function actually has a flaw, which is that the newly loaded function is placed in the scope of the previous load function. The more functions are loaded, the deeper the stack level, which obviously consumes a lot of performance. However, W3C attributes functions such as onclick, onload, onmouseout, etc. to the event model of DOM0. The advantage is that they have a wide range of applications, but they are based on their performance. Therefore, it proposes the event model of DOM1.0 and the event model of DOM2.0. DOM2 is a combination of the original Microsoft event model and the event model of the original Netscape. It can both capture and bubble, and it binds multiple types of events without causing the latter to cover the former. So people always create famous addEvent functions, and we use addEvent to modify our event loading.


OK, no problem. The above onReady function has an optional parameter for whether to wait for the image to be loaded. We know that the JS engine will only start processing pictures and audio and other things after completing the DOM tree, but what if our pages rely heavily on script layout? ! We want to make the page appear in a general shape as soon as possible, so we use domReady. We improve it on the original basis.

dom standard browser uses DOMContentLoaded, which is a very realistic W3C DOM method. It is different from FF's DOMMouseScroll. Basically, all browsers that are not IE kernel support it. In IE, we can judge whether the DOM tree is completed by listening to document. documentElement. doScroll(). The principle is that in IE, we can only doScroll after the DOM tree is built. But it is not perfect yet. It cannot determine whether the content of the iframe has been loaded under IE. We continue to improve it.

We are simply reimplementing jquery's $(document).ready(function(){ })! It has a very powerful function and is basically invulnerable to the namespace made of closures. And it only pollutes one global variable "JS", which can be comparable to YUI (laugh). However, for general applications, we don’t need to be so comprehensive. If we don’t need to process the image and the page does not have an iframe, we can do the following mini version.