Ambiguity in the interpretation of optional parameters

Question

The jQuery .on function .on is equal to

$ (elements) .on (events [, selector] [, data], handler);

where selector and data are optional. Therefore function call

$ (elements) .on (var1, var2, var3);

can be interpreted using var2 as either selector or as data . Is there any ambiguity?

More generally, how is the ambiguity from optional parameters handled for any other jQuery function?

Answer 1

If only one of the selector and data parameters is provided, and the value is a string, it is assumed to be a selector.

From jQuery doco for .on() :

The data argument can be of any type, but if a string is used, the selector must either be provided or explicitly passed as null so that the data is not erroneous for the selector. It is best to use an object (map) so that multiple values ​​can be passed as properties.

A similar principle applies to other jQuery methods with optional parameters.

Answer 2

A selector is a string and data is an object. The test should be something like.

 if (typeof var2 === 'string') { // var2 is selector } else { // var2 is data } 

Change the actual jQuery source from https://github.com/jquery/jquery/blob/master/src/event.js

 on: function( types, selector, data, fn, /*INTERNAL*/ one ) { var origFn, type; // Types can be a map of types/handlers if ( typeof types === "object" ) { // ( types-Object, selector, data ) if ( typeof selector !== "string" ) { // ( types-Object, data ) data = selector; selector = undefined; } for ( type in types ) { this.on( type, selector, data, types[ type ], one ); } return this; } 

Answer 3

In the above example, the selector and data arguments assume different types of objects. The selector argument must be a string, and data must be an Object. They can be differentiated between using the typeof operator. For example:

 if(typeof selector === "string") { //We know that the 2nd argument is actually a selector string } 

Note that if you need to pass String to on as the data argument, you must also specify the selector argument (even if you just go null ).

Answer 4

Here is a bit of jquery source. Basically, they look for parameter types and, if necessary, assign them other parameters. For example, if the element in the “selector” position in the parameter list is not a string, they assume that it should be the “data” parameter, etc.

 on: function( types, selector, data, fn, /*INTERNAL*/ one ) { var origFn, type; // Types can be a map of types/handlers if ( typeof types === "object" ) { // ( types-Object, selector, data ) if ( typeof selector !== "string" ) { // ( types-Object, data ) data = selector; selector = undefined; } for ( type in types ) { this.on( type, selector, data, types[ type ], one ); } return this; } if ( data == null && fn == null ) { // ( types, fn ) fn = selector; data = selector = undefined; } else if ( fn == null ) { if ( typeof selector === "string" ) { // ( types, selector, fn ) fn = data; data = undefined; } else { // ( types, data, fn ) fn = data; data = selector; selector = undefined; } } 

Answer 5

I have my own problems with .on (), and ...

The context of this has always been very clear with the vs bind delegate (or any binding shortcut). Now with on context can change a lot ...

For example,

 //This is pretty clear, you now want to turn the paragraph tag red when clicked $('p').on('click', function () { $(this).css('color', 'red'); }); //Woah... so the context of `this` just changed by a single argument //this now refers to all anchor tags that are descendants of paragraph tags. $('p').on('click', 'a', function () { $(this).css('color', 'red'); }); 

This is a FIRST jQuery method that ever changes the context of this , simply passing another argument.

A quick fact - delegate - (in 1.4.2) was the first way not to use a selector to represent the context of the callback function. But at least everything was clear ... when you see .delegate (), you understand what is happening.