How to understand JavaScript event loading 02/22 Update SLTechnology News&Howtos

How to understand JavaScript event loading

2025-02-22 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to understand JavaScript event loading". In daily operation, I believe many people have doubts about how to understand JavaScript event loading. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts of "how to understand JavaScript event loading"! Next, please follow the editor to study!

JavaScript event loading itself is not a complex function; generally speaking, _ window.onload is sufficient. If we want to load multiple events, we can do the following:

_ window.onload = function () {func1 (); func2 (); func3 (); / / more load events... }

But if there is some special need, can't we write together? For example, the current area is for the administrator, when the background generates the page, only when the user is the administrator, the page generates this part, and this part also uses some special scripts, the above method will stop!

JavaScript event loading: embarrassment between foreground and background

/ / background code

< script type="text/javascript">

_ window.onload = function () {func1 (); func2 (); / / load scripts used by ordinary users. }

< /script>

< %# 以下脚本是为管理员准备的 %>

< % if @user.role == "manager" %>

_ window.onload = function () {func1 (); func2 (); / / load secret scripts. }

< % end %>

The resulting page in this case has two _ window.onload code blocks, and it is clear that the second overwrites * *. At this point, it's time for the loadEvent function to come out.

Var loadEvent = function (fn) {var oldonload = _ window.onload; if (typeof _ window.onload! = 'function') {_ window.onload = fn;} else {_ window.onload = function () {oldonload (); fn ();}

It solves the problem of mutual coverage very much, and its usage is as follows:

LoadEvent (func1); loadEvent (func2); loadEvent (func3); / / more load events

But the real problems are always so unexpected and so tricky. Recently I want to put all the functions in a closure to avoid naming conflicts, such as the famous $DOM selector. JQuery,Prototype,mootool uses it as the name of the selector, and coexistence becomes a serious problem.

Reported an error, saying that the node could not be found. Why can't you find it? Because when we call it, the DOM tree hasn't been built yet! No way, the web page is so complete in front of us. This is related to the operation of the closure. When the JS engine parses to a "}" of the closure, it locks the contents into a sealed environment, and the JS continues to execute downward, which cannot modify the properties of the window in the closure. Window has a famous attribute called document, which references the entire DOM tree (among other things). The DOM tree is a complex key-value pair, and as the JS continues to parse downward, the corresponding nodes are constantly added to the document. But when it is stuffed into the closure, the time inside stands still, so it is still in the stage of parsing head, document is incomplete, if you want to get the nodes in body, of course you have to return null. So the crux of the problem is how to get the document in the closure to continue to parse downwards. There are two methods, one is to use listeners (addEventListener and attachEvent), and the other is to use timeline-based setTimeout and setInterval.

OK, no problem. The above onReady function has an optional argument to determine whether the image has been loaded. We know that the JS engine will not start processing things such as pictures and audio until the DOM tree is completed, but what if our page relies heavily on script layout?! We want to make the page appear in general shape as soon as possible, so we use domReady. We improve it on the original basis.

Dom standard browsers use DOMContentLoaded, which is a very real W3C approach to DOM. Unlike FF's DOMMouseScroll, basically all browsers with non-IE kernels support it. Under IE, we can listen to document. DocumentElement. DoScroll () to determine whether the DOM tree is completed, the principle is that under IE only when the DOM tree has been built can doScroll. But it is not perfect, it can not determine whether the content of iframe is loaded or not under IE. We continue to improve it.

We are simply reimplementing jquery's $(document) .ready (function () {})! It is very powerful, with the use of closures made of namespaces, basically bulletproof. And it pollutes only one global variable, "JS", which is comparable to YUI (laughter). But for general applications, we don't have to be so comprehensive. If we don't need to process the picture and there is no iframe on the page, we can do the following miniature version.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.