I see 2 main ways to set events in JavaScript:
Add an event directly inside the tag like this:
do foo
Set them by JavaScript like this:
<a id="bar" href="">do bar</a>
and add an event in a <script> section inside the <head> section or in an external JavaScript file, like that if you're using prototypeJS:
Event.observe(window, 'load', function() {
$('bar').observe('click', doBar);
}
I think the first method is easier to read and maintain (because the JavaScript action is directly bound to the link) but it's not so clean (because users can click on the link even if the page is not fully loaded, which may cause JavaScript errors in some cases).
The second method is cleaner (actions are added when the page is fully loaded) but it's more difficult to know that an action is linked to the tag.
Which method is the best?
A killer answer will be fully appreciated!
I think the first method is easier to read and maintain
I've found the opposite to be true. Bear in mind that sometimes more than one event handler will be bound to a given control.
Declaring all events in one central place helps to organize the actions taking place on the site. If you need to change something you don't have to search for all places making a call to a function, you simply have to change it in one place. When adding more elements that should have the same functionality you don't have to remember to add the handlers to them; instead, it's often enough to let them declare a class, or even not change them at all because they logically belong to a container element of which all child elements get wired to an action. From an actual code:
$$('#itemlist table th > a').invoke('observe', 'click', performSort);
This wired an event handler to all column headers in a table to make the table sortable. Imagine the effort to make all column headers sortable separately.
In my experience, there are two major points to this:
1) The most important thing is to be consistent. I don't think either of the two methods is necessarily easier to read, as long as you stick to it. I only get confused when both methods are used in a project (or even worse on the same page) because then I have to start searching for the calls and don't immediately know where to look.
2) The second kind, i.e. Event.observe() has advantages when the same or a very similar action is taken on multiple events because this becomes obvious when all those calls are in the same place. Also, as Konrad pointed out, in some cases this can be handled with a single call.
I believe the second method is generally preferred because it keeps information about action (i.e. the JavaScript) separate from the markup in the same way CSS separates presentation from markup.
I agree that this makes it a little more difficult to see what's happening in your page, but good tools like firebug will help you with this a lot. You'll also find much better IDE support available if you keep the mixing of HTML and Javascript to a minimum.
This approach really comes into its own as your project grows, and you find you want to attach the same javascript event to a bunch of different element types on many different pages. In that case, it becomes much easier to have a single pace which attaches events, rather than having to search many different HTML files to find where a particular function is called.
You can also use addEventListener (not in IE) / attachEvent (in IE).
Check out: http://www.quirksmode.org/js/events_advanced.html
These allow you to attach a function (or multiple functions) to an event on an existing DOM object. They also have the advantage of allowing un-attachment later.
In general, if you're using a serious amount of javascript, it can be useful to make your javascript readable, as opposed to your html. So you could say that onclick=X in the html is very clear, but this is both a lack of separation of the code -- another syntactic dependency between pieces -- and a case in which you have to read both the html and the javascript to understand the dynamic behavior of the page.
My personal preference is to use jQuery in external js files so the js is completely separate from the html. Javascript should be unobtrusive so inline (ie, the first example) is not really the best choice in my opinion. When looking at the html, the only sign that you are using js should be the script includes in the head.
An example of attaching (and handling) events might be something like this
var myObject = {
allLinkElements: null,
init: function()
{
// Set all the elements we need
myObject.setElements();
// Set event handlers for elements
myObject.setEventHandlers();
},
clickedLink: function()
{
// Handle the click event
alert('you clicked a link');
},
setElements: function()
{
// Find all <a> tags on the page
myObject.allLinkElements = $('a');
// Find other elements...
},
setEventHandlers: function()
{
// Loop through each link
myObject.allLinkElements.each(function(id)
{
// Assign the handler for the click event
$(this).click(myObject.clickedLink);
});
// Assign handlers for other elements...
}
}
// Wait for the DOM to be ready before initialising
$(document).ready(myObject.init);
I think this approach is useful if you want to keep all of your js organised, as you can use specific objects for tasks and everything is nicely contained.
Of course, the huge benefit of letting jQuery (or another well known library) do the hard work is that cross-browser support is (largely) taken care of which makes life much easier
Libraries like YUI and jQuery provide methods to add events only once the DOM is ready, which can be before window.onload. They also ensure that you can add multiple event handlers so that you can use scripts from different sources without the different event handlers overwriting each other.
So your practical choices are;
One. If your script is simple and the only one that will ever run on the page, create an init function like so:
window.onload = function () {
init();
}
function init() {
// actual function calls go here
doFoo();
}
Two. If you have many scripts or plan to mashup scripts from different sources, use a library and its onDOMReady method to safely add your event handlers
Related
I tried to have a title that match the context I want my answer for.
I explain myself.
After writting thousand of javascript lines of code (with or without jquery) I finally asked myself if I'm doing it wrong.
Mainly thanks to jQuery adding event/delegating to an element is very easy, but all the example are quiet "easy"; meaning it doesn't take into account that you have a page full of list, button, dynamic things...
So my questions, is:
Once again for a complexe website, with hundred of dynamic pages, ajax navigation, millions of user...
Is there any advantage (beside simplicity) to place a global listener (body or whatever) and let all events bubble up ?
When I look at angular it seems they listen 'ng-click' globally, but I can missthink.
Contexte
<body>
<div>
<ul>
<li><span click="myFunc"></span></li>
</ul>
</div>
</body>
-
Sidenot: I'm using jQuery for presentation/simplicity, but it's global question about js
// Standard binding example
$('span').on('click', func)
vs
// Standard delegation example
$('ul').on('click', 'span', func)
vs
// Dispatcher for 'block'
$('ul').on('click', localDispatcher)
vs
// One (and only one) Global Listener for all click
$(body).on('click', globalDispatcher)
With this example, the 3 first one need to be placed manually, on a dedicated js for this page.
Vs
The last one is just a simple event listener, that will use click attribute to dispatch and can be set just once and for all.
I find the last one very cool, because it remove all the hassle to manage click/selector/dom management. Also I don't have to .off every listener when I change page (ajax navigation).
But I wonder about performance or maybe another problems I can think about (that's why I ask the question :D).
I really wonder how "big web startup" manage this kind of Javascript.
Thanks :)
I'd say no to a global listener since it will make things incredibly confusing and frustrating to organize once the app grows into a considerable size.
Also the performance should be really bad since you are involving elements that will be ignored otherwise.
So stick with element or block level event delegation if you want to feel good about yourself in the future!
For example:
File a.html includes 5 javascript files. When I click the share btn () how can I know from which js file I have included that my click action came from.
I see a couple possible situations. I will give each situation and how I would approach the problem.
The button binds to the javascript:
This is the case where the button would be in the form where the ... is the function to call. In order for this to work, the name of the function has not been uglified, even if the rest of the file has. In this case, you should be able to open each of your 10 files in your favorite text editor and just search for that function name. Easy.
The javascript binds to the button:
This is the case that I see as most likely given the tiny example you gave us. This is where the button is given some class (perhaps sns-share?) and the javascript is somehow looking for the button in the DOM and binding to its click event.
What I would do for this is similar to the above, with a couple extra steps. First, run each of your files through a "beautifier" (http://jsbeautifier.org/ is an example) to make them easier to read. This won't fix variable names or anything like that; it only makes the structure easier to read. Next, open the beautified files in your favorite text editor. Search for the class name that is used (in your case, this might be sns-share). Unless the code is deliberately obfuscated, the class name string should show up somewhere. Find this string, and intelligently read through the code, finding out where it is used. If you can find the spot where the javascript finds all elements with that class and binds a click handler to them, you have found your function.
The actual binding may take a couple different forms. Perhaps:
$(".sns-share").click(function () ....
if they are using jQuery. Or maybe:
var elements = jQuery(".sns-share");
elements.bind('click', function () ...
Maybe they didn't use any wrapper libraries and went with straight up DOM stuff:
var elements = document.getElementsByClassName('sns-share');
for (var i = 0; i < elements.length; i++) {
element.onclick = function () ...
}
Or, something completely different if they are going for IE6 compatibility or something. You need to be on the lookout for what is going on.
Note:
Either one of these processes depend on some things:
You are willing to read the code intelligently. You can't just blindly stare at it...you need to think about it what is doing.
The code hasn't been deliberately obfuscated. If this is the case, you're going to have a harder time finding where stuff is happening. In this case, I would just rewrite the entire program.
Another note:
If it is the 2nd case above and you are having a hard time finding a place to start to look for the actual function being bound, you can inspect the element in Chrome (right click the button, select "Inspect element" and look at the Event Listeners (it should be in the panel on the left). Look for the click event and expand it. All functions listening for the click event will be shown there. If jQuery is used, this won't be of much help since it might be hard to find the function wrapped by the jQuery event, but if they didn't use jQuery or something and bound directly to the DOM element, this will point exactly to the function that is going to be executed.
I have been struggling with choosing unobtrusive javascript over defining it within the html syntax. I want to convince my self to go the unobtrusive route, but I am having trouble getting past the issues listed below. Can you please help convince me :)
1) When you bind events unobtrusively, there is extra overhead on the client's machine to find that html element, where as when you do stuff, you don't have to iterate the DOM.
2) There is a lag between when events are bound using document.ready() (jquery) and when the page loads. This is more apparent on very large sites.
3) If you bind events (onclick etc) unobtrusively, there is no way of looking at the html code and knowing that there is an event bound to a particular class or id. This can become problematic when updating the markup and not realizing that you may be effecting javascript code. Is there a naming convention when defining css elements which are used to bind javascript events (i have seen ppl use js_className)
4) For a site, there are different pieces of javascript for different pages. For example Header.html contains a nav which triggers javascript events on all pages, where as homepage.html and searchPage.html contains elements that trigger javascript on their respective pages
sudo code example:
header.html
<script src="../myJS.js"></script>
<div>Header</div>
<ul>
<li>nav1</li><li>nav2</li>
</ul>
homepage.html
<#include header.html>
<div class="homepageDiv">some stuff</div>
searchpage.html
<#include header.html>
<div class="searchpageDiv">some other stuff</div>
myJS.js
$(document).ready(function(){
$("ul.li").bind("click",doSomething());
$(".homePageDiv").bind("click",doSomethingElse());
$(".searchPageDiv").bind("click",doSomethingSearchy());
});
In this case when you are on the searchPage it will still try to look for the "homepageDiv" which does not exist and fail. This will not effect the functionality but thats an additional unnecessary traversal. I could break this up into seperate javascript files, but then the browser has to download multiple files, and I can't just serve one file and have it cached for all pages.
What is the best way to use unobtrusive javascript so that I could easily maintain a ( pretty script heavy) website, so another developer is aware of scripts being bound to html elements when they are modifying my code. And serve the code so that the client's browser is not looking for elements which do not exist on a particular page (but may exist on others).
Thanks!
You are confused. Unobtrusive JavaScript is not just about defining event handlers in a program. It's a set of rules for writing JavaScript such that the script doesn't affect the functionality of other JavaScript on the same page. JavaScript is a dynamic language. Anyone can make changes to anything. Thus if two separate scripts on the same page both define a global variable add as follows, the last one to define it will win and affect the functionality of the first script.
// script 1
var add = function (a, b) {
return a + b;
};
// script 2
add = 5;
//script 1 again
add(2, 3); // error - add is a number, not a function
Now, to answer your question directly:
The extra overhead to find an element in JavaScript and attach an event listener to it is not a lot. You can use the new DOM method document.querySelector to find an element quickly and attach an event listener to it (it takes less than 1 ms to find the element).
If you want to attach your event listeners quickly, don't do it when your document content loads. Attach your event listeners at the end of the body section or directly after the part of your HTML code to which you wish to attach the event listener.
I don't see how altering the markup could affect the JavaScript in any manner. If you try to attach an event listener to an element that doesn't exist in JavaScript, it will silently fail or throw an exception. Either way, it really won't affect the functionality of the rest of the page. In addition, a HTML designer really doesn't need to know about the events attached any element. HTML is only supposed to be used for semantic markup; CSS is used for styling; and JavaScript is used for behavior. Don't mix up the three.
God has given us free will. Use it. JavaScript supports conditional execution. There are if statements. See if homePageDiv exists and only then attach an event listener to it.
Try:
$(document).ready(function () {
$("ul.li").bind("click",doSomething());
if (document.querySelector(".homePageDiv")) {
$(".homePageDiv").bind("click",doSomethingElse());
} else {
$(".searchPageDiv").bind("click",doSomethingSearchy());
}
});
Your question had very little to do with unobtrusive JavaScript. It showed a lack of research and understanding. Thus, I'm down voting it. Sorry.
Just because jQuery.ready() executes does not mean that the page is visible to the end user. This is a behaviour defined by browsers and these days there are really 2 events to take into consideration here as mootools puts it DomReady vs Load. When jQuery executes the ready method it's talking about the dom loading loaded however this doesn't mean the page is ready to be viewed by the user, external elements which as pictures and even style sheets etc may still be loading.
Any binding you do, even extremely inefficient ones will bind a lot faster than all the external resources being loaded by the browser so IMHO user should experience no difference between the page being displayed and functionality being made available.
As for finding binding on elements in your DOM. You are really just fearing that things will get lost. This has not really been my actual experience, more often than not in your JS you can check what page you are on and only add javascript for that page (as Aadit mentioned above). After that a quick find operation in your editor should help you find anything if stuff gets lost.
Keep in mind that under true MVC the functionality has to be separate from the presentation layer. This is exactly what OO javascript or unobtrusive javascript is about. You should be able to change your DOM without breaking the functionality of the page. Yes, if you change the css class and or element id on which you bind your JS will break, however the user will have no idea of this and the page will at least appear to work. However if this is a big concern you can use OO-Javascript and put div's or span's as placeholders in your dom and use these as markers to insert functionality or tell you that it exists, you can even use html comments. However, in my experience you know the behavior of your site and hence will always know that there is some JS there.
While I understand most of your concerns about useless traversals, I do think you are nickle and dime'ing it at this point if you are worried about 1 additional traversal. Previous to IE8 it used to be the case that traversing with the tag name and id was a lot faster than my selector but this is no longer true infact browsers have evolved to be much faster when using just the selectors:
$("a#myLink") - slowest.
$("a.myLink") - faster.
$("#Link") - fastest.
$(".myLink") - fastest.
In the link below you can see that as many as 34 thousand operations per second are being performed so I doubt speed is an issue.
You can use firebug to test the speed of each in the case of a very large dom.
In Summary:
a) Don't worry about losing js code there is always ctrl+f
b) There is no lag because dom ready does not mean the page is visible to start with.
Update
Fixed order of speed in operations based on the tests results from here
However keep in mind that performances of IE < 8 are really had if you don't specify the container (this used to be the rule, now it seems to be the exception to the rule).
In my answer to the following SO question: What does event binding mean?, I made a passing remark that the use of inline-JavaScript/Early-Binding to bind JavaScript Events was 'often misguided'
For example:
<input id="MyButton" type="button" value="clickme" onlick="Somefunction()" />
I was arguing for the 'late-binding' approach where there is no JavaScript referenced in the markup, which I understand to be established best-practice. However, the commenters asserted that there were occasions that necessitated its use, and I wondered what these might be.
Without engaging in a discussion on the relative merits of either, can anyone think of any circumstances that dictate that you use the (e.g.) onclick attribute over a late-binding approach.
commenters asserted that there were occasions that necessitated its use
I suppose I'm one of those commentors. What I actually said was that inline listeners "are a reasonable option in certain circumstances". I don't think there are any cases where it is "necessitated" (which I understand in this context to mean required).
Adding inline listeners is simply applying the same logic on the server to add listeners as would be applied on the client and has advantages in that:
Markup can be created and cached or used as static pages, listeners aren't added by every client over and over again when pages are downloaded
Issues related to delay between the element being available and the listener being added by DOMReady or onload functions or "bottom scripts" are completely removed
The vagaries of various "cross browser" DOMReady functions with onload fallback are removed - there is no opportunity for such functions to fail to add listeners if they aren't used
Of course this doesn't mean that all listeners should be added inline and that dynamic addition of listeners is rubbish, I'm just point out that it is a viable method that solves certain issues and is a perfectly reasonable solution in many cases.
If you believe "early binding" of listeners is good, then make it as early as possible - put them inline. :-)
PS. I also think I said I didn't like the use of "binding" in this context as listeners aren't bound to elements in any real sense. They are simply functions that are called when an element receives a related event. The only type of binding is that the listener's this keyword may be set to reference the related element (which is consistent in all browsers for inline listeners but not necessarily for those added later).
Reasons why onclick attributes are bad :
onclick="foo()"
Your passing in a string of code that get's evalled at runtime when the element is clicked. This is inefficient and uses the horrors of eval
Your forced to store the function foo in global scope thus polluting global scope with all your event handling logic.
I think many developers will do this either due to ignorance or lack of knowledge (which is, of course, common) and the remaining developers will do it because it's simply more convenient to use HTML-JS attributes than late binding, if you know that certain objects and functions are always loaded on every page and they will simply 'be there'.
I think this is especially true when said HTML comes from an AJAX callback. Take an example where an AJAX request comes back with an HTML response and that HTML is inserted into the page. Now the naive developer would think along these lines:
I have no idea what elements are inside that response HTML so I don't know what late bindings I need to add.
Perhaps I need to add them all just in case! Or write some parsing script that detects elements and binds to the ones I find?
But what if I need to bind to something that doesn't already exist? Time to write some long inline JavaScript!
All of this can be eliminated by using a kind of omnipresent binding that applies to all current and future elements on the page. In jQuery, the equivalent is live(). Instead of writing:
$('.foo').click(function(){...});
You could write:
$('.foo').live('click', function(){...});
Now, all elements with class name 'foo' will execute the function when clicked, including elements that don't currently exist. Very useful for dynamic AJAX interfaces.
You may know that already, but I'm just pointing out that anything JS attributes can do, pure JS can do better, and I'd consider that best practise.
I'm using window.onload to call my JavaScript code that has to be executed after the page is fully loaded. From what I read this is the recommended method to call such scripts.
However, it does not work for some Ajax sites, www.bing.com for instance - window.onload is called before the pages is fully rendered.
Any suggestions?
The short answer is that there's no general way to solve this problem (right now).
The definition of a "page" is pretty fungible when AJAX comes into play - it's pretty hard to tell the difference between AJAX that is intended to be part of the initial page load, and that which might not be. So, browsers are left on their own to determine when window.onload() should be fired, and it doesn't always end up where you want.
Luckily, most people don't need a general solution, but rather a specific one. If you care about bing.com, then you can probably look at how bing.com works and design your code to trigger when the site reaches a state that you find acceptable.
I've wrestled with this a couple of times, and my usual reason for needing some sort of onload event triggering is to be able to interact with the HTML DOM and have getElementById, getElementsByTagName, or various other DOM selectors, return something other than nothing.
Once again, I'm not sure of the exact problem you are trying to solve, but if you must use some sort of onload, and it's because of DOM traversal of some kind, you can cheat a bit with the following sort of code:
window.onload = pageChecker;
function pageChecker() {
// Onload has fired, but we don't trust it.
// Check to see if our deepest nested element can be found
var testElement = document.getElementById("importantElement");
if ( !testElement ) {
// Try again in a bit, adjust timeout to what your users
// can tolerate
setTimeout(pageChecker, 50);
}
else {
//
// ... the element exists, run important code below ...
//
}
}
You might be able to listen for changes and requests by globally listening for DOMSubtreeModified and readystatechange events, and use those events instead of the load event for whatever you are trying to do.
I'd recomend using jQuerys $(...).ready() method.
In addition to the answer from Rasmus Kaj and if you are using jQuery, I would direct you to take a look at Global Ajax Event Handlers.
jQuery.fn.ajaxComplete (http://api.jquery.com/ajaxcomplete/)
jQuery.fn.ajaxStop (http://api.jquery.com/ajaxstop/)
Note, that this has nothing to do with the native onload event.