With the different ways of adding events in javascript, do any of them take priority like css classes do? For example will an inline onclick even always fire before one added with addEventListener?
If not, is there any way to give an event priority?
Yes
An inline onclick handler is going to bind as the DOM is loading
Whereas anything you add with .on or .addEventListener will have to wait for the DOM element to load first.
See here: http://jsfiddle.net/DmxNU/
Your html
click
Your js (jQuery in this case)
$(function() {
$("a").click(console.log.bind(console, "world"));
});
Output
hello
world
Explanation
I'm not sure where this would be documented, but think about it this way. If you're going to use the DOM API to query an element and then add an event listener, that element has to be loaded first. If that element already contains an onclick attribute, that will already be attached first.
JavaScript events don't take any priorities. When and event is fired it is added to an event queue and executed as soon as possible.
You can claim that it is a general rule that onclick attribut events will always trigger first, and that will always be true, but it's not because they are prioritized.
Quoted from #Kevin B's comment
Related
This question already has answers here:
Event binding on dynamically created elements?
(23 answers)
Closed 7 years ago.
I have a <select> form element that is being generated dynamically after the page loads. I was using jQuery to attach a change event that would update other fields in the form, and wanted to eliminate the need to rewire the handler each time the form containing the <select> was replaced.
For click events on dynamic elements, I have been moving to unobtrusive JavaScript and wanted to use that approach for change - but no success. Attaching to the <select>directly was cumbersome because when the node is replaced in the DOM, the connected event listener dies with it, and the new node must be attached to again.
So I wanted to know, is there a way to unobtrusively assign a change event handler to the parent element of a newly-created <select> and let the event bubble up to a handler on a previously-existing element, in order to avoid attaching a handler each time a new target input element is created?
Yes!
$('#StaticParentNode').on('change',"select.qualifiers", function(){
alert("Change detected from parent");
});
Naturally, I finally got this working 2 minutes after posting my original answer (below). Doh.
No.
While attaching unobtrusive event listeners on a parent <div> or the document works great for bubbling click events from elements that didn't previously exist on the page, you can only attach an event listener to an element that has that type of event.
As stated in the jQuery .change API docs (although this issue is not jQuery specific):
The change event is sent to an element when its value changes. This event is limited to <input> elements, <textarea> boxes and <select> elements.`
Since <div> and document do not have a change event, they cannot intercept one from their children either.
Solutions:
Just set onchange to a previously-defined function when you generate the element: <select onchange='MyModule.selectChanged()'>[<options>]</select>. Not pure from a separation of concerns standpoint, but a simple approach with minimal extra HTML added to an AJAX request, and no fiddling with handlers after the AJAX call completes.
or,
(Re)attach an event listener each time you create new elements that require it, either 'manually' (e.g. in a $.ajax success function) or by wiring it into whatever tool is handling your AJAX results (e.g. modifying or extending .prototype). See examples elsewhere on SO.
Hi I'm developing my view in JS and I'm stuck in binding a click handler for my horizontal layout element. I've tried using Jquery
$("#myHorizontalLayout").bind("click",function(){window.alert()});
Which didn't work then I tried using attachPress with the element which obviously didn't exist. Please help.
Update:
The JS view is the default view of the application.
When on/bind does not work, it could be that the HTML of the control has actually not been created yet at this point in time. But even if you delay the binding, the re-rendering (re-creation of the HTML after changes) would remove your listener, at least when bound on the control itself.
A proper way of doing this is using the generic attachBrowserEvent function available on every control (here: on the layout) which internally handles all the rendering/rerendering stuff, see this example:
http://jsbin.com/hijutunefi/1/edit?html,output
attachBrowserEvent works for any browser event, as it attaches a new browser event listener to the root node of the control. For the most common browser events UI5 does event delegation, so for the "click" event and several others addEventDelegate can also be used, as pointed out by aborjinik.
Alternatively, listening on the <body> level with normal jQuery mechanisms should in general also work.
Which didn't work then I tried using attachPress with the element which obviously didn't exist. Please help.
Does this means that the element on which you are attaching event handler doesn't exists at this point? If this is the case you can hook the handler to some container, upper in the DOM hierarchy which you are sure that exists and filter the click events.
Example:
$("body").on("click", "#myHorizontalLayout", function(){
alert("Hey, you!");
});
As of jQuery 1.7, the .on() method is the preferred method for
attaching event handlers to a document. For earlier versions, the
.bind() method is used for attaching an event handler directly to
elements. Handlers are attached to the currently selected elements in
the jQuery object, so those elements must exist at the point the call
to .bind() occurs.
Reference here
So try replacing bind with on and let me know if it works or not.
Assuming I have this code, button with inline onclick event:
<button onclick='..js stuff..'>mybutton</button>
I have this button created multiple times because of server-side loop.
Or I would be better giving a class to these buttons, and just do (using jQuery):
$(".button-class").on('click',function(){..});
What is better in terms of performance?
My questions are-
In the inline onclick, does it creates a handler for each button?
In jQuery event binding, does the handler is created only once, and is binded for each button, or, here as well, the handler is created multiple times?
I guess that these are the factors which affect any performance difference. Perhaps the only downside for .on(..) is that I have to do DOM search by class name. (?)
The answer is: it doesn't matter.
Use the latter (jQuery binding) because it moves the code away from the DOM and makes it easier to work with.
With the inline attribute a different handler is theoretically added for each event; each attribute implicitly creates a new callback/function1 that wraps the supplied code. This handler will be replaced if the attribute (or corresponding DOM property) is assigned a different value later. In the case when all the event handlers have been created this is the "worst" approach in terms of book-keeping.
With the jQuery (addEventListener) version the same function callback is added for all the matching elements. Multiple event handlers for the same element/event may be added; care may be required to avoid unintentional repeated-binding.
Furthermore, with delegated events jQuery could avoid binding to each element separately (ie. it only binds one event handler further up the propagation chain). Depending on how many elements are to have events "attached", this could result in a significant decrease of actual events listened to while still only using a single event handler function.
The chance of their being an actual real-world performance difference between the approaches is slim-to-none, degenerate cases aside. Use the form that is most clear/extensible/maintainable which, IMOHO, is rarely the event properties; especially when embedded directly into HTML attributes. (One issue with the inline attribute form is that it cannot bind to an appropriate closure context and so it must use - ick! - global context in many cases.)
1 Browsers first only had inline events (almost exclusively specified in HTML attributes) and are well-optimized for this case. The actual event handler function is only created on demand. Consider the case of <button onclick="alert(">Hi!</button>, where the "onclick" contains a syntax error in the inline JavaScript. A modern browser will only parse the JS (and thus only create the actual handler function) when the the button is clicked or the .onclick property is read.
Using onclick is frowned upon and considered bad form, you should instead be using element.on('click') with jQuery or ng-click in Angular.js.
They both result in the same number of listeners, and basically the same performance.
The counter part using on.event is: if you reload Or rerender the objects using akax you need to instanciate the on.event again, it creates more code and thats more complicated.
I'm currently trying to write what I feel like should be a very simple chrome addon using jquery. I have a tool I use for work that our IT department has stopped supporting Chrome with, because they have enough on their plate troubleshooting IE. Their solution however, was simply to remove the old onClick functions and added the property disabled="diabled" to all of our buttons.
My simple work around for this is using jquery to remove the disabled properly and append the onClick functionality. I've gotten this to work in a few instances, but the problem I'm running into is with new instances of buttons created using ajax forms.
Here's the code I'm currently trying to work with:
function restoreFunctionality() {
$("#RestoreDefaultsButton").removeProp("disabled").attr("onClick", "OnRestoreDeviceClientClick()");
}
RestoreFunctionality();
Now, this works fine for the initial load, however I'd also like this to work for every button that is to be created in the future. To do this, I added:
$("#RestoreDefaultsButton").on("restoreFunctionality", function(event) {
$("#RestoreDefaultsButton").removeProp("disabled").attr("onClick", "OnRestoreDeviceClientClick()");
});
This, however, does not work for me but also does not provide any sort of console error message telling me why it won't work. I can't seem to find an example of what I want. I see examples in the jquery doc where it can be called by clicking somewhere or something like that, however what I want is for it to just simply "work". Just look for new instances of that button ID and make the changes.
Is on() not the function I want to use in jquery 1.11.1? Am I somehow using this incorrectly? Any guidance to point me in the right direction would help.
Edit for clarification:
I am not trying to edit the same button multiple times in multiple locations. I am trying and willing to create code individually for each button that comes up, given I know the ID of each one.
Here is an example of something I have that is currently working:
The line of code for the button reads:
<input type="button" name="RestoreDefaultsButton" value="Submit"
id="RestoreDefaultsButton" disabled="disabled" class="aspNetDisabled InlineButtonStyle">
The code that I am using and that actually works just fine is now:
$("body").on("click", "#RestoreDefaultsButton", restoreDefaultFunctionality());
and restoreDefaultFunctionality() is simply:
$("#RestoreDefaultsButton").removeProp("disabled").attr("onClick", "OnRestoreDeviceClientClick()");
Again, the above code works just fine. What I seem to have trouble with is that not all of my buttons are present on load, I may click a link that loads a model on the same page/url with a form that has additional buttons. That button might read:
<input type="button" name="OpenToolkitButton" value="Submit" id="OpenToolkitButton" disabled="disabled" class="aspNetDisabled InlineButtonStyle">
Which is almost exactly the same as the original example, it's just been loaded after the script ran for the first time.
What I am looking for is a solution to make all individually specified buttons that I need, when they occur, to have that disabled removed and a specific onclick function added.
It appears that you have several things wrong and you are using .on() incorrectly.
First, ids in your document must be unique. You cannot have multiple DOM elements with the same id. That is both illegal HTML and will not correctly work with selectors. So, if you're trying to detect future "#RestoreDefaultsButton" objects in addition to the one you already have, you will have to change that because you can't have more than one and still have selector code work correctly. Usually, you want to use a class name instead of an id when you want to find multiple objects of the same type.
Second, your use of .on() is simply not correct. .on() allows you to register a callback function that will be called when a certain DOM event is triggered. So, when you do this:
$("#RestoreDefaultsButton").on("restoreFunctionality", fn);
You are asking for jQuery to call your function when the single "#RestoreDefaultsButton" object triggers the "restoreFunctionality" DOM event. Since "restoreFunctionality" is not a built-in DOM event, the only way that could ever trigger is if you triggered the event yourself.
The usual solution to modifying newly created objects that are inserted into the DOM is to go find the code that creates those objects and insert a function call (to call your own function that can find and "patch up" the newly created DOM objects right AFTER the newly created DOM objects have been created.
The newest browser versions allow you to register a callback to be notified when certain types of objects are added to the DOM so you could get notified automatically. These notifications are call MutationObservers (doc here). Unfortunately, those events are only implemented in the latest browsers (IE11) so you generally can't solely rely on them for a general web page.
Your click handler assignment could probably be solved with delegated event handling. In delegated event handling for dynamically created objects, you find a persistent object (that is not dynamically created) that will be in the parent chain of your dynamically created element and you bind the click event handler to that parent. Since click events "bubble" up the parent chain, the click event will be seen by the parent. Using the delegated form of .on() that works like this:
$("static parent selector").on("click", "dynamic element selector", fn);
You can then handle the event without worrying about the timing of when the dynamic element is created/destroyed, etc...
You can read more about delegated event handling in these references:
Does jQuery.on() work for elements that are added after the event handler is created?
jQuery .live() vs .on() method for adding a click event after loading dynamic html
jQuery .on does not work but .live does
Are you triggering the "restoreFunctionality" event after your ajax forms are built?
$("#RestoreDefaultsButton").trigger("restoreFunctionality");
Forces it to be synchronous if you have more to do after the call and before you finish the function
$("#RestoreDefaultsButton").triggerHandler("restoreFunctionality");
I'm just testing out replacing a whole page with another page using JavaScript and I found this answer with document.write. As to why document.write, I needed to replace the entire HTML, including scripts and styles using the same page.
It does what I want but i can't seem to have consistency with my event handlers. My handlers are all attached to document using:
$(document).delegate(...);
Currently, I have weird results. In a fiddle I made, it attaches a handler. When clicked, the event fires, rewrites the page, runs the function again - but it doesn't attach the handler.
However in my project, I'm doing the same routine (d.w(), then add handlers). It does reattach once and handlers work, but after doing a second routine (still on the same page), it doesn't attach anymore.
So my questions are:
When using d.w(), do existing handlers get erased from document?
Are window as well as document the same after subsequent d.w()s? or are they somehow "renewed"
Do scripts that are already parsed stay in memory and run after subsequent d.w()s? Or do they get erased as well?
(The following applies to google chrome)
Only the document is cleared, the scripts in memory still stay the same. You can easily test it by setting something to a variable and see if it exists after clearing out the document with .open.
The old native handler is therefore lost from the document, but jQuery still thinks that the handler exists in its own event model. You can see it by editing the log to:
console.log('patch', JSON.stringify($.cache ));
jQuery only ever attaches a single native handler per event, so if you have a "click" event registered on document, further handlers attached with jQuery don't attach a new native handler, instead the handler is pushed into the jQuery internal handlers array.
Now, because document.open removed the native handler, but doesn't clear javascript, jQuery still thinks the native handler exists, and further .delegate only goes to the jQuery internal handler array. If you replace your handler with plain old document.onclick you will see it starts working.
You can also keep using jQuery if you add $(document).unbind() (or more robust $.cache = {};, but this is internal and subject to change) before the .delegate, so that jQuery is again synced. Otherwise it won't be, since it has no idea you called document.open.
So:
Yes
They are still the same objects, can be tested by saving a reference and checking that agaist document after a .open
They stay in memory.
http://jsfiddle.net/wphzt/4/
The only reason it stops working from second time onwards is because in your function you have written
document.write('<span>'+(++i)+'</span>');
In which case, next time the document doesn't have the delegate function to increment the span value but has only what you have written in the code snippet I have highlighted above. Thus, as you doubted, yes they get erased as well. Hope this helps.