We Keep Coding

Is there a name for the programming paradigm jQuery suggests? [duplicate]

I have heard many times that using JavaScript events, such as onClick(), in HTML is a bad practice, because it's not good for semantics. I would like to know what the downsides are and how to fix the following code?
link

You're probably talking about unobtrusive Javascript, which would look like this:
link
with the logic in a central javascript file looking something like this:
$('#someLink').click(function(){
popup('/map/', 300, 300, 'map');
return false;
});
The advantages are
behaviour (Javascript) is separated from presentation (HTML)
no mixing of languages
you're using a javascript framework like jQuery that can handle most cross-browser issues for you
You can add behaviour to a lot of HTML elements at once without code duplication

If you are using jQuery then:
HTML:
<a id="openMap" href="/map/">link</a>
JS:
$(document).ready(function() {
$("#openMap").click(function(){
popup('/map/', 300, 300, 'map');
return false;
});
});
This has the benefit of still working without JS, or if the user middle clicks the link.
It also means that I could handle generic popups by rewriting again to:
HTML:
<a class="popup" href="/map/">link</a>
JS:
$(document).ready(function() {
$(".popup").click(function(){
popup($(this).attr("href"), 300, 300, 'map');
return false;
});
});
This would let you add a popup to any link by just giving it the popup class.
This idea could be extended even further like so:
HTML:
<a class="popup" data-width="300" data-height="300" href="/map/">link</a>
JS:
$(document).ready(function() {
$(".popup").click(function(){
popup($(this).attr("href"), $(this).data('width'), $(this).data('height'), 'map');
return false;
});
});
I can now use the same bit of code for lots of popups on my whole site without having to write loads of onclick stuff! Yay for reusability!
It also means that if later on I decide that popups are bad practice, (which they are!) and that I want to replace them with a lightbox style modal window, I can change:
popup($(this).attr("href"), $(this).data('width'), $(this).data('height'), 'map');
to
myAmazingModalWindow($(this).attr("href"), $(this).data('width'), $(this).data('height'), 'map');
and all my popups on my whole site are now working totally differently. I could even do feature detection to decide what to do on a popup, or store a users preference to allow them or not. With the inline onclick, this requires a huge copy and pasting effort.

It's not good for several reasons:
it mixes code and markup
code written this way goes through eval
and runs in the global scope
The simplest thing would be to add a name attribute to your <a> element, then you could do:
document.myelement.onclick = function() {
window.popup('/map/', 300, 300, 'map');
return false;
};
although modern best practise would be to use an id instead of a name, and use addEventListener() instead of using onclick since that allows you to bind multiple functions to a single event.

With very large JavaScript applications, programmers are using more encapsulation of code to avoid polluting the global scope. And to make a function available to the onClick action in an HTML element, it has to be in the global scope.
You may have seen JS files that look like this...
(function(){
...[some code]
}());
These are Immediately Invoked Function Expressions (IIFEs) and any function declared within them will only exist within their internal scope.
If you declare function doSomething(){} within an IIFE, then make doSomething() an element's onClick action in your HTML page, you'll get an error.
If, on the other hand, you create an eventListener for that element within that IIFE and call doSomething() when the listener detects a click event, you're good because the listener and doSomething() share the IIFE's scope.
For little web apps with a minimal amount of code, it doesn't matter. But if you aspire to write large, maintainable codebases, onclick="" is a habit that you should work to avoid.

Revision
Unobtrusive JavaScript approach was good in the PAST - especially events handler bind in HTML was considered as bad practice (mainly because onclick events run in the global scope and may cause unexpected error what was mention by YiddishNinja)
However...
Currently it seems that this approach is a little outdated and needs some update. If someone want to be professional frontend developper and write large and complicated apps then he need to use frameworks like Angular, Vue.js, etc... However that frameworks usually use (or allow to use) HTML-templates where event handlers are bind in html-template code directly and this is very handy, clear and effective - e.g. in angular template usually people write:
<button (click)="someAction()">Click Me</button>
In raw js/html the equivalent of this will be
<button onclick="someAction()">Click Me</button>
The difference is that in raw js onclick event is run in the global scope - but the frameworks provide encapsulation.
So where is the problem?
The problem is when novice programmer who always heard that html-onclick is bad and who always use btn.addEventListener("onclick", ... ) wants to use some framework with templates (addEventListener also have drawbacks - if we update DOM in dynamic way using innerHTML= (which is pretty fast) - then we loose events handlers bind in that way). Then he will face something like bad-habits or wrong-approach to framework usage - and he will use framework in very bad way - because he will focus mainly on js-part and no on template-part (and produce unclear and hard to maintain code). To change this habits he will loose a lot of time (and probably he will need some luck and teacher).
So in my opinion, based on experience with my students, better would be for them if they use html-handlers-bind at the beginning. As I say it is true that handlers are call in global scope but a this stage students usually create small applications which are easy to control. To write bigger applications they choose some frameworks.
So what to do?
We can UPDATE the Unobtrusive JavaScript approach and allow bind event handlers (eventually with simple parameters) in html (but only bind handler - not put logic into onclick like in OP quesiton). So in my opinion in raw js/html this should be allowed
<button onclick="someAction(3)">Click Me</button>
or
function popup(num,str,event) {
let re=new RegExp(str);
// ...
event.preventDefault();
console.log("link was clicked");
}
link
But below examples should NOT be allowed
<button onclick="console.log('xx'); someAction(); return true">Click Me</button>
link
The reality changes, our point of view should too

There are a few reasons:
I find it aids maintenence to separate markup, i.e. the HTML and client-side scripts. For example, jQuery makes it easy to add event handlers programatically.
The example you give would be broken in any user agent that doesn't support javascript, or has javascript turned off. The concept of progressive enhancement would encourage a simple hyperlink to /map/ for user agents without javascript, then adding a click handler prgramatically for user agents that support javascript.
For example:
Markup:
<a id="example" href="/map/">link</a>
Javascript:
$(document).ready(function(){
$("#example").click(function(){
popup('/map/', 300, 300, 'map');
return false;
});
})

It's a new paradigm called "Unobtrusive JavaScript". The current "web standard" says to separate functionality and presentation.
It's not really a "bad practice", it's just that most new standards want you to use event listeners instead of in-lining JavaScript.
Also, this may just be a personal thing, but I think it's much easier to read when you use event listeners, especially if you have more than 1 JavaScript statement you want to run.

Your question will trigger discussion I suppose. The general idea is that it's good to separate behavior and structure. Furthermore, afaik, an inline click handler has to be evalled to 'become' a real javascript function. And it's pretty old fashioned, allbeit that that's a pretty shaky argument. Ah, well, read some about it #quirksmode.org

onclick events run in the global scope and may cause unexpected
error.
Adding onclick events to many DOM elements will slow down the
performance and efficiency.

Two more reasons not to use inline handlers:
They can require tedious quote escaping issues
Given an arbitrary string, if you want to be able to construct an inline handler that calls a function with that string, for the general solution, you'll have to escape the attribute delimiters (with the associated HTML entity), and you'll have to escape the delimiter used for the string inside the attribute, like the following:
const str = prompt('What string to display on click?', 'foo\'"bar');
const escapedStr = str
// since the attribute value is going to be using " delimiters,
// replace "s with their corresponding HTML entity:
.replace(/"/g, '"')
// since the string literal inside the attribute is going to delimited with 's,
// escape 's:
.replace(/'/g, "\\'");
document.body.insertAdjacentHTML(
'beforeend',
'<button onclick="alert(\'' + escapedStr + '\')">click</button>'
);
That's incredibly ugly. From the above example, if you didn't replace the 's, a SyntaxError would result, because alert('foo'"bar') is not valid syntax. If you didn't replace the "s, then the browser would interpret it as an end to the onclick attribute (delimited with "s above), which would also be incorrect.
If one habitually uses inline handlers, one would have to make sure to remember do something similar to the above (and do it right) every time, which is tedious and hard to understand at a glance. Better to avoid inline handlers entirely so that the arbitrary string can be used in a simple closure:
const str = prompt('What string to display on click?', 'foo\'"bar');
const button = document.body.appendChild(document.createElement('button'));
button.textContent = 'click';
button.onclick = () => alert(str);
Isn't that so much nicer?
The scope chain of an inline handler is extremely peculiar
What do you think the following code will log?
let disabled = true;
<form>
<button onclick="console.log(disabled);">click</button>
</form>
Try it, run the snippet. It's probably not what you were expecting. Why does it produce what it does? Because inline handlers run inside with blocks. The above code is inside three with blocks: one for the document, one for the <form>, and one for the <button>:
let disabled = true;
<form>
<button onclick="console.log(disabled);">click</button>
</form>
Since disabled is a property of the button, referencing disabled inside the inline handler refers to the button's property, not the outer disabled variable. This is quite counter-intuitive. with has many problems: it can be the source of confusing bugs and significantly slows down code. It isn't even permitted at all in strict mode. But with inline handlers, you're forced to run the code through withs - and not just through one with, but through multiple nested withs. It's crazy.
with should never be used in code. Because inline handlers implicitly require with along with all its confusing behavior, inline handlers should be avoided as well.

Javascript: finding a function's code

This is one of the first time's I'm looking at javascript, so please excuse the newbish question.
I'm trying to read the code for a specific function on a website that is of interest to me. I didn't write anything for the website, so cannot really comment on the general structure. This is almost like reverse engineering. Where it's called (in a js/main.js) looks like:
$(document).ready(function() {
$('#search').funcA();
From what I understand this is saying from the file/class or whatever that comesf rom the id search, call funcA. My questions is: how do I see the file that is called with #search?

funcA is almost certainly a jQuery plugin (or part of jQuery itself). The first thing I would try in your situation is searching for "jQuery funcA" on Google.
Whether or not it is actually part of jQuery, you can see the source for that function by running:
$('#search').funcA
in a REPL, such as your browser's console, or:
console.log( $('#search').funcA );
as long as the toString function for that function hasn't been overwritten and it is not a reference to a native function.

funcA appears to be defined as a jQuery method; try
console.log($.fn.funcA)

Open javascript console in the same browser window (I used chrome) that is displaying the page that contains that code. Then just execute this line:
> $('#search').funcA
You should see the body of funcA. Random example output when I did $("#myownid").show:
function funcA (a,b,c){var d,e;if(a||a===0)return
this.animate(cu("show",3),a,b,c);for(var
g=0,h=this.length;g
...
If you manage to see the body of the function, you should be able to infer likely sources (or post them here and we should be able to point you further)

The console.log suggestions here are nice use of Function.prototype.toString (and in some browsers some console magic), but I'd use debugger instead. Chrome has quite nice debugging tools for stuff like this and the debugger statement will get you there with ease.
var test = $('#search').funcA;
debugger;
Open the console and start investigating. When the execution of your code hits that breakpoint, you'll see handy tools like this
Right-clicking test there should also give you the option to "Show function definition" which will show you where the function was actually defined as source code.
And if you want to investigate even further from there, you can always set similar breakpoints right from the Chrome dev console.

Short version: Open the console and run $("#search") it will return a jquery object containing the dom node that has an id of search.
Long version:
$("something")
Is jquery (a java script library) for select elements by css selector returning a jquery object.
https://learn.jquery.com/using-jquery-core/selecting-elements/
$(document).ready(function() {
Is jquery for when my document (basically the page) is ready for me to muck with run this anonymous function.
https://learn.jquery.com/using-jquery-core/document-ready/
$('#search').funcA();
Selects a set of elements, in this case the single element with id "search" and then run funcA on each of them using the element as the scope. So it would run funcA on the element with ID "search" with the search node being the value of the special scope variable (scope is referenced through the key word "this", it can get rather complex).
So in essence what your seeing is:
When my document is ready find the search element and run my function funcA on it.

Why "$().ready(handler)" is not recommended?

From the jQuery API docs site for ready
All three of the following syntaxes are equivalent:
$(document).ready(handler)
$().ready(handler) (this is not recommended)
$(handler)
After doing homework - reading and playing with the source code, I have no idea why
$().ready(handler)
is not recommended. The first and third ways, are exactly the same, the third option calls the ready function on a cached jQuery object with document:
rootjQuery = jQuery(document);
...
...
// HANDLE: $(function)
// Shortcut for document ready
} else if ( jQuery.isFunction( selector ) ) {
return rootjQuery.ready( selector );
}
But the ready function has no interaction with the selector of the selected node elements, The ready source code:
ready: function( fn ) {
// Attach the listeners
jQuery.bindReady();
// Add the callback
readyList.add( fn );
return this;
},
As you can see, it justs add the callback to an internal queue( readyList) and doesn't change or use the elements in the set. This lets you call the ready function on every jQuery object.
Like:
regular selector: $('a').ready(handler) DEMO
Nonsense selector: $('fdhjhjkdafdsjkjriohfjdnfj').ready(handler) DEMO
Undefined selector:$().ready(handler) DEMO
Finally... to my question: Why $().ready(handler) is not recommended?

I got an official answer from one of the jQuery developers:
$().ready(fn) only works because $() used to be a shortcut to $(document) (jQuery <1.4)
So $().ready(fn) was a readable code.
But people used to do things like $().mouseover() and all sorts of other madness.
and people had to do $([]) to get an empty jQuery object
So in 1.4 we changed it so $() gives an empty jQuery and we just made $().ready(fn) work so as not to break a lot of code
$().ready(fn) is literally now just patched in core to make it work properly for the legacy case.
The best place for the ready function is $.ready(fn), but it's a really old design decision and that is what we have now.
I asked him:
Do you think that $(fn) is more readable than $().ready(fn) ?!
His answer was:
I always do $(document).ready(fn) in actual apps and typically there's only one doc ready block in the app it's not exactly like a maintenance thing.
I think $(fn) is pretty unreadable too, it's just A Thing That You Have To Know Works™...

Since the different options do pretty much the same thing as you point out, it's time to put on the library writer hat and make some guesses.
Perhaps the jQuery people would like to have $() available for future use (doubtful since $().ready is documented to work, even if not recommended; it would also pollute the semantics of $ if special-cased).
A much more practical reason: the second version is the only one that does not end up wrapping document, so it's easier to break when maintaining the code. Example:
// BEFORE
$(document).ready(foo);
// AFTER: works
$(document).ready(foo).on("click", "a", function() {});
Contrast this with
// BEFORE
$().ready(foo);
// AFTER: breaks
$().ready(foo).on("click", "a", function() {});
Related to the above: ready is a freak in the sense that it's (the only?) method that will work the same no matter what the jQuery object wraps (even if it does not wrap anything as is the case here). This is a major difference from the semantics of other jQuery methods, so specifically relying on this is rightly discouraged.
Update: As Esailija's comment points out, from an engineering perspective ready should really be a static method exactly because it works like this.
Update #2: Digging at the source, it seems that at some point in the 1.4 branch $() was changed to match $([]), while in 1.3 it behaved like $(document). This change would reinforce the above justifications.

I would say its simply the fact that $() returns an empty object whereas $(document) does not so your applying ready() to different things; it still works, but I would say its not intuitive.
$(document).ready(function(){}).prop("title") // the title
$().ready(function(){}).prop("title") //null - no backing document

More than likely this is just a documentation bug and should be fixed, the only downside to using $().ready(handler) is it's readability. Sure, argue that $(handler) is just as unreadable. I agree, that's why I don't use it.
You can also argue that one method is faster than another. However, how often do you call this method enough times in a row on a single page to notice a difference?
Ultimately it comes down to personal preference. There is no downside to using $().ready(handler) other than the readability argument. I think the documentation is miss-leading in this case.

Just to make it patently obvious that there is some inconsistency in the three, plus I added the fourth often used form: (function($) {}(jQuery));
With this markup:
<div >one</div>
<div>two</div>
<div id='t'/>
and this code:
var howmanyEmpty = $().ready().find('*').length;
var howmanyHandler = $(function() {}).find('*').length;
var howmanyDoc = $(document).ready().find('*').length;
var howmanyPassed = (function($) { return $('*').length; }(jQuery));
var howmanyYuck = (function($) {}(jQuery));
var howmanyYuckType = (typeof howmanyYuck);
$(document).ready(function() {
$('#t').text(howmanyEmpty + ":" + howmanyHandler + ":"
+ howmanyDoc + ":" + howmanyPassed + ":" + howmanyYuckType);
});
The displayed results of the div from the last statement are: 0:9:9:9:undefined
SO, only the Handler and Doc versions are consistent with the jQuery convention of returning something of use as they get the document selector and with the Passed form you must return something (I wouldn't do this I would think, but put it in just to show "inside" it has something).
Here is a fiddle version of this for the curious: http://jsfiddle.net/az85G/

I think this is really more for readability than anything else.
This one isn't as expressive
$().ready(handler);
as
$(document).ready(handler)
Perhaps they are trying to promote some form of idiomatic jQuery.

Overwrite jQuery to execute code after element has become visible - how to?

I am developing a small javascript framework for internal use in our company. In some cases our framework is overwriting basic jQuery functionality in order to handle internal logic or fix browser bugs etc. I want these cases to be completely transparent for our developers so they can just keep using jQuery the way they are used to.
I have come across a problem that I can’t seem to get my head around to do in a nice transparent way – at least I can’t come up with a good way to do it - so I turn to you :).
What I want to do is overwrite jQuery in a way so I can execute a certain piece of code each time something “becomes visible”. For instance if a developer runs the show() method, I want to execute my code after the element has become visible. In fact no matter how the developer “makes an element visible” (e.g. show(), css(), animate() etc.) I want my code to run
I know that show() for instance has a “callback” parameter that can be used for just that. But the point is; this should be totally transparent for the developer. He does not need to know that this code is “run underneath”.
All my overwrites is done using closures, so I can save a reference to the original method, do my thing and execute the original. Here is an example of how I am doing this with the show method:
(function ($) {
var originalShowMethod = jQuery.fn.show;
jQuery.fn.show = function (speed, easing, callback) {
// Do stuff before
var theReturn = jQuery(originalShowMethod.call(this, speed, easing, callback));
// Do stuff after
return theReturn;
};
})(jQuery);
My initial approach was to just simply do it this way (running my code at “// Do stuff after”). That also works great except when you are passing a speed parameter (because then it's using something like setTimeout or setInterval internally), or using one of the other “show an element” methods.
Is there some master “show an element” method in jQuery that I can overwrite so all methods that has something to do with “showing elements” will be affected by my piece of code? Or do I have to overwrite all "showing methods"? Can anyone give an example of how I can accomplice this task? and what i need to overwrite if that's the way to do it.
Thanks in advance.

I think you want something like the .is() and the :visible selector, it sounds like you might want to run a function like this using setInterval
function checkElementVis(){
if($(".element").is(":visible")){
alert("is visible");
} else {
alert("not visible");
}
}

what is the difference between $("#context .searched") and $(".searched",$("#context"))?

I had that question in mind for a long time.
Theoretically, jQuery core function accepts an optional value that can be a DOM element - $(".searched",$("#context")[0]) - or a jQuery object - $(".searched",$("#context") ) .
I discovered that last question reading that fine article.
But i really cant see the difference between use a context and pass a more complex css expression. If there is no difference in the way it works, is there any perfomance difference?
Thanks

It gets converted to a DOM element (in Sizzle, the context portion) to search in either of your cases, ultimately doing a .find() under the covers.
If you're concerned about performance (why not be as fast as possible?), you should use this instead:
$("#context .searched")
This version gets converted back into a jQuery object:
$("#context")[0]
So it's a bit slower on the jquery side, since it has to be wrapped in a jquery object before the .find() call, that performance difference is very minimal, but it's the only difference so I'm noting it :)

The major difference would be that $(".searched", context); can take a variable as a context as well. It is effectively doing $(context).find('.searched'); under the hood, and I think the second version is more readable anyway, so I usually use that.
The use for this situation would be something like this:
$.fn.highlightSearch = function() {
return this.each(function() {
$('.searched', this).addClass('highlighted');
// the commented line performs the same thing:
// $(this).find('.searched').addClass('highlighted');
});
};
$('#context').highlightSearch();
$('.somethingElse').highlightSearch();
Notice that in this case, you can't simply append the new selector on the end of the original.
If you have no other reason to hold a copy of $('#context'), then using $('#context .searched') is going to be quicker, and simpler. However, if you already had $('#context') stored in a variable, its better to use .find(select) or the $(selector, context) form to search for your contained elements.

Readability: a CSS selector like $("#context .searched") is far more readable than the other.