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

This article introduces the knowledge of "how to monitor page DOM changes and respond efficiently in javascript". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Starting from DOM change event monitoring

First of all, assuming that you already know the occurrence stage of the event in JavaScript (capture-bubbling), attach a picture to show this content, and we go straight to the process of finding a solution.

Graphical representation of an event dispatched in a DOM tree using the DOM event flow

In the beginning, I have been looking for the events involved in the window state change, and after searching around, I found that the onload event was the closest, so let's take a look at MDN's definition of the event:

The load event is fired when a resource and its dependent resources have finished loading.

How do you understand that resources and their dependent resources have been loaded? To put it simply, if a page involves image resources, the onload event will trigger after the page is fully loaded (including images, css files, and so on). A simple listening event should be written in JavaScript (note the differences between load and onload in different environments):

Window.addEventListener ("load", function (event) {console.log ("All resources finished loading!");}); / / or _ window.onload=function () {console.log ("All resources finished loading!");}; / / HTML

/ jQuery $(window) .on ("load", handler)

Of course, when it comes to onload events, there is a similar event in jQuery that must be mentioned-the ready event. This event is defined in jQuery as follows:

Specify a function to execute when the DOM is fully loaded.

What you need to know is that the ready events defined by jQuery are essentially designed for DOMContentLoaded events, so the events that should be distinguished when we talk about loading are actually onload (interface UIEvent) and DOMContentLoaded (interface Event), as MDN describes DOMContentLoaded:

When the initial HTML document is fully loaded and parsed, the DOMContentLoaded event is triggered without waiting for the stylesheet, images, and subframes to finish loading. A different event, load, should only be used to detect a fully loaded page.

So you know that when a page loads, DOMContentLoaded should be triggered first and then onload. Similar events and differences include the following categories:

DOMContentLoaded: when the initial HTML document is fully loaded and parsed, the DOMContentLoaded event is triggered without waiting for the stylesheet, images, and subframes to finish loading

Readystatechange: the Document.readyState property of a document describes the loading state of the document. When this state changes, this event is triggered.

Load: the load event is triggered when a resource and its dependent resources have finished loading

Beforeunload: the beforeunload event is triggered when a browser window, document, or its resources is about to be unloaded.

Unload: the unload event is triggered when a document or a child resource is being unloaded.

If you are more careful, you will find that the above mentioned UIEvent and Event in the introduction of the event. What is this? These are events-behaviors that can be detected by JavaScript. Other event interfaces include KeyboardEvent / VRDisplayEvent (yes, yes, this is the VR you are interested in and familiar with) and so on. If you do a little search in the search engine, you will find that some materials about events can be divided into the following categories:

UI event

Focus event

Mouse and wheel event

Keyboard and text events

Compound event

Change event

HTML5 event

Device event

Touch and gesture events

But it's a bit messy to write in this way, some of which are events defined by DOM3, some of which are listed separately, and if you are familiar with them, you will find that this is the narrative pattern in JavaScript advanced programming. In my opinion, understanding these events can be distinguished by DOM3 events and other events: DOM3 level events specify the following types of events-UI events, focus events, mouse events, wheel events, text events, keyboard events, composite events, change events, change name events The rest, such as HTML5 events, can be understood separately. The Event mentioned at the beginning, as a primary interface, is the implementation parent of many events. The Web API interface can be found here, and there are a lot of Event words in it.

Well, after all the events, we still haven't solved the question we just asked. What if we listen to dynamically generated elements on the page? Considering that dynamically generated elements need to obtain resources through network requests, is it possible to listen to all HTTP requests? Looking at the jQuery documentation, you can see that every time an Ajax request completes, the jQuery triggers the ajaxComplete event, and at this point all handlers are registered and executed using the .ajaxComplete () method. But who can guarantee that all ajax will go from jQuery? So you should choose among the change events, let's take a look at the following change events defined by DOM2:

DOMSubtreeModified: when there is any change in the structure of the DOM. This event will be triggered after other events are triggered.

DOMNodeInserted: triggered when a node is inserted into another node as a child node

DOMNodeRemoved: triggered when a node is removed from its parent node

DOMNodeInsertedIntoDocument: triggered after a node is inserted directly into the document or indirectly through a subtree. This event is triggered after DOMNodeInserted

DOMNodeRemovedFromDocument: triggers before a node is removed from the document directly or indirectly through a subtree. This event is triggered after DOMNodeRemoved

DOMAttrModified: triggered after the feature has been modified

DOMCharacterDataModified: triggered when the value of a text node changes

So, it seems right to use DOMSubtreeModified. The elder brother reminded me to use MutationObserver, so he found a new continent. MDN describes MutationObserver as follows:

MutationObserver provides developers with the ability to respond appropriately to changes in a range of DOM trees. The API is designed to replace the Mutation event introduced in the DOM3 event specification.

Mutation events in the DOM3 event specification can be seen simply as an extension of the Mutation event defined in the DOM2 event specification, but these are not important because they are all going to be replaced by MutationObserver. OK, so let's introduce MutationObserver in detail. The article "MutationObserver API" gives a more detailed introduction to the use of MutationObserver, so I'll pick a few points that can directly solve our needs.

Now that you want to listen for changes in DOM, let's take a look at what Observer does:

It waits for all script tasks to complete before it runs asynchronously.

It encapsulates DOM change records into an array for processing, rather than dealing with DOM changes individually.

It can observe not only all types of changes that occur in DOM, but also certain types of changes.

The constructor of MutationObserver is relatively simple. You can pass in a callback function (the callback function accepts two parameters, * is a variable array, and the second is an observer instance):

Let observer = new MutationObserver (callback)

The observer instance uses the observe method to listen, the disconnect method to stop listening, and the takeRecords method to clear the change record.

Let article = document.body; let options = {'childList': true,' attributes':true}; observer.observe (article, options)

The * * parameter in the observe method is the variable DOM element to be observed, and the second parameter receives the type of change to be observed (child node change and attribute change). The types of changes include the following:

ChildList: changes in child nodes.

Attributes: changes in attributes.

CharacterData: changes in node content or node text.

Subtree: changes in all descendant nodes.

To observe which type of change you want, specify its value as true in the option object. It is important to note that if the setting observes changes in subtree, one or more of childList, attributes, and characterData must be specified at the same time. The disconnect method and the takeRecords method can be called directly without passing in parameters.

OK, we have completed the monitoring of DOM changes, so refresh the code to see the effect. Since the page consists of many dynamically generated products, I should add change monitoring on body, so options should be set like this:

Var options = {'attributes': true,' subtree': true}

Huh? Pull down the page a little bit to trigger the observer dozens of times? How can DOM bear this? looking at the change records of the page, it is found that the Node.insertBefore () method is called at the bottom of each new resource.

Let's talk about the cutoff / throttling function in JavaScript.

One of the troubles now is that DOM changes so frequently that it takes too much resources to monitor every change. A simple solution is for me to give up listening and use the setInterval method to perform update logic on a regular basis. Yes, although the method is a little primitive, its performance is much better than that of Observer.

At this time, there was another brother's assist: "use the intercepting function." I remember that when I saw the essence of JavaScript language before, I saw that the self-calling of setTimeout method was used to solve the phenomenon that the frequent execution of setInteval ate resources. I don't know if the two are related. A search on the Internet found that there are two "jie stream functions". The demand comes from here:

In front-end development, pages are sometimes bound to frequently triggered events such as scroll or resize events, which means that the bound program will be called many times within normal operation. However, sometimes javascript has a lot of things to deal with, and frequent departure will lead to performance degradation, page stutters and even browser crashes.

If we reuse the setTimeout and clearTimeout methods, we seem to be able to solve this frequently triggered execution. Each time an event is triggered, I first determine if there is a setTimeout timer, if so, we clear it first, and then create a new setTimeout timer to delay my response behavior. This sounds good because we don't execute our response immediately every time, and we can keep the response function there all the time (and only one) during frequent triggers, except for some delayed responses. Yes, this is the interception function (debounce), and there is a blog post about it with this short story:

The metaphor of the image is a rubber ball. If you hold your finger on the rubber ball, it will be under pressure and will not bounce back until you let go. The focus of debounce is on idle intervals.

In my business, the following interception function is called in the observer instance.

/ * * fn execute function * context binding context * timeout delay value * * / let debounce = function (fn, context, timeout) {let timer; / / pass the content out using closures return function () {if (timer) {/ / clear timer clearTimeout (timer) } / / set a new timer timer = setTimeout (function () {fn.apply (context, arguments)}, timeout);}}

Of course, I have solved my own problem, but there is still one concept that has not been mentioned-"throttling function". An example is also used in the same blog post to illustrate it:

The metaphor of the image is a faucet or a machine gun, and you can control its flow or frequency. The focus of throttle is on successive execution intervals.

The principle of function throttling is also very simple, it is still a timer. When I trigger a time, setTimout delays the event for a while. If the event is triggered during this interval, we clear the original timer and setTimeout a new timer to delay execution for a while. The starting point of function throttling is to make a function not to be executed too frequently and to reduce some excessive calls to throttling. This is explained by the throttling code implementation of AlloyTeam:

/ / parameters var throttle = function (fn, delay, mustRunDelay) {var timer = null; var tweak start; return function () {var context = this, args = arguments, t_curr = + new Date (); / / clear timer clearTimeout (timer); / / function initialization judgment if (! t_start) {t_start = t_curr } / / timeout (specified time interval) judge if (t_curr-t_start > = mustRunDelay) {fn.apply (context, args); t_start = current;} else {timer = setTimeout (function () {fn.apply (context, args);}, delay);} That's all for the content of "how to listen for DOM changes and respond efficiently in javascript". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.