How to better monitor changes in element attributes ()

As we all know, jquery has an onchange event to determine events similar to input or textarea tag value changes.

In jquery, values change is monitored through events such as keyup, blur, and click. If the value changes, the change event is triggered.

jQuery.event.special.change = {        filters: {            focusout: testChange,             beforedeactivate: testChange,             click: function( e ) {                var elem = e.target, type = elem.type;                 if ( type === "radio" || type === "checkbox" || elem.nodeName.toLowerCase() === "select" ) {                    testChange.call( this, e );                }            },             // Change has to be called before submit            // Keydown will be called before keypress, which is used in submit-event delegation            keydown: function( e ) {                var elem = e.target, type = elem.type;                 if ( (e.keyCode === 13 && elem.nodeName.toLowerCase() !== "textarea") ||                    (e.keyCode === 32 && (type === "checkbox" || type === "radio")) ||                    type === "select-multiple" ) {                    testChange.call( this, e );                }            },             // Beforeactivate happens also before the previous element is blurred            // with this event you can‘t trigger a change event, but you can store            // information            beforeactivate: function( e ) {                var elem = e.target;                jQuery._data( elem, "_change_data", getVal(elem) );            }        },         setup: function( data, namespaces ) {            if ( this.type === "file" ) {                return false;            }             for ( var type in changeFilters ) {                jQuery.event.add( this, type + ".specialChange", changeFilters[type] );            }             return rformElems.test( this.nodeName );        },         teardown: function( namespaces ) {            jQuery.event.remove( this, ".specialChange" );             return rformElems.test( this.nodeName );        }    };

Yui3 also has a module called value-change module. yui3 uses a 50-millisecond timer to regularly check value changes.

In fact, at the beginning, I was wondering why the browser has a native event of listening for value changes, but neither Yui nor jquery is used?

Let's talk about the native solution:

There are onpropertychange and onchange events in IE to monitor attribute changes under an element.

Onchange Introduction

Fires when the contents of the object or selection have changed.

Http://msdn.microsoft.com/en-us/library/ms536912 (V = vs.85). aspx

Example: http://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/onchangeEX.htm

In fact, onchange is triggered in Blur, that is, when the focus is lost. This is obviously not what we want

So what about onpropertychange?

Fires when a property changes on the object.

Http://msdn.microsoft.com/en-us/library/ms536956 (V = vs.85). aspx

Example: http://samples.msdn.microsoft.com/workshop/samples/author/dhtml/refs/onpropertychangeEX.htm

Well, maybe in IE, onpropertychange is more appropriate and can be triggered directly when the value is changed.

In addition to Internet Explorer, the solution is a breeze.

First, Firefox has its own watch method, which is used by El. watah ("property", callback), which can be used to listen to property changes for all object types, detailed in the https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/watch

A common method is the input event. all browsers except ie support this event. However, ie9 now supports the input event, the difference between this event and onpropertychange is that the input event only listens for changes in the content text, that is, changes to the value.

Occurs when the text content of an element is changed through the user interface.

Because the change to the value is actually a change to the DOM tree (the DOM tree is not only a structure, but also its content and attributes), we can use the mutation event of Dom Level 2, for exampleDomattrmodified

So let's go back to the previous question: Why didn't jquery and Yui choose to use the native interfaces provided by these browsers?

Written in MDN:

It shoshould be noted that the presence of any mutation event listeners in a document degrades the performance of subsequent Dom operations in that document. in simple tests that can mean that a DOM operation takes between 1.5 and 7 as long as it wowould without any mutation listener. more information can be found in the "performance impact of Dom mutation listeners" threadin Mozilla. dev. platform.

So what is the link provided by it?

Boris zbarsky explained this question:

Mutation listeners cause slowdown in two ways:

1) Firing the event takes time O (tree depth at which mutation
Happened), with a constant that can be easily be comparable to
Cost of the mutation itself.
2) creating the event object between des varous operations to grab
Information mutation event objects carry (e.g. The old and new
Values for attribute changes); generating this can be expensive,
Because generating the string representation of some attributes is
Expensive (thing multi-dozen-kilobyte SVG path attribute, or large
Inline style block), and because conversion from our internal types
To the ones mutation events want is expensive for nodes.

Since this section is important, I 'd like to translate it.

1. the time complexity of triggering an event is O (the size changes with the DOM depth of the modification). With this variable O, we can clearly understand the size of this loss.

2. when creating an event object, various operations are included. These operations need to capture the information of the mutation event object, such as the pre-modification value and the modified value (to be compared ). It is resource-consuming to execute these operations, because it is resource-consuming to generate a string for these values for comparison (such as a bunch of SVG path attributes or a large number of inline styles ). It is time-consuming to convert an internal type to a mutation event object.

So why not use oninput?

This is because the input event can only listen to the input of textarea, type is password or text. Input such as type = checkbox cannot be processed, and the display is not general enough.

After straighten out the above, I began to understand the reasons for the respective choice of Yui and jquery.

-- End -- original address: http://www.f2es.com/better-way-listen-change/, thanks to the original author to share

How to better monitor changes in element attributes ()