I am applying an event listener function when elements are inserted into the document via the DOMNodeInserted event. Elements are inserted in rapid succession, but I'd only like to have my function executed once per batch of element insertions.
I have tried using a boolean variable with global scope within my closure to denote whether or not the function called by the listener should actually take the action, coupled with setTimeout to reset this variable after the events have finished firing.
jQuery is being used for other functionality within this project, so it is an open option to consider here, but perhaps the abstraction is not incredibly helpful in this case. I have noticed the .one() method. Perhaps it is possible to bind an event handler which gets cancelled as soon as it is fired once and then re-established with the timeout?
Suggestions?
You could use the method that you suggested (using .one() and reattaching after a timeout), but it sounds like debounce (waiting until a burst of function calls ends before calling the handler, or calling the handler only once at the beginning of a batch of function calls) is what you're looking for. You could try John Hann's implmentation of bebounce or try Ben Alman's jQuery debounce plugin.
Related
I don't even know where to begin. I'm using Kendo Grid to list data sourced from a server. Everything is fine on first load including when I add additional functions and dom elements in the dataBound function. Calls to the server seemingly update (sync) the Grid just fine. BUT, it seems the dataBound function is called an additional time the second time round. Performing an on click function coded in the dataBound performs it a total of 4 times. How do I test for where the issue is and what do I need to destroy to stop this infuriating behaviour?
I don't even know what code to give you save for pasting in my whole website. What is the underlying theory behind this behaviour because there's obviously something I am fundamentally missing about how javascript, and therefore Kondo, works? How do I test for this, please. Thanks!
A quick solution might be to use off() then on() in the databound e.g.
$(".cell").off("click").on("click", function(e){ ... });
this will get rid of previously attached handlers and ensure you only have one.
Even better, use event delegation outside of the Grid generating code.
$(document).on("click", ".cell", function(e) { ... });
With event delegation, the target of the event does not have to exist at the time the event handler is setup. In the example above, the click is on the document object which already exists, but the handler will only fire if an element with the class 'cell' is actually clicked. You can define this handler once in the document.ready before the grid is even created.
Once removeEventListener is invoked, is it safe to assume that the removed handler will not be called? This is a somewhat broad question, so here are some specific examples.
A button is clicked, and its click event is dispatched onto the execution queue. Before the event can be handled, removeEventListener is called, removing the button's event handler. What happens?
A function is invoked which takes 3 milliseconds to complete. At the end of this function, removeEventListener is invoked, removing the click handler of a button. During this three-millisecond period, the button is clicked. Will the handler be invoked after the previous function is done executing?
Is it safe to perform cleanup actions in the same function that invokes removeEventListener, or must one use setTimeout or some other method of first ensuring that the execution queue is empty? Does this behavior vary among browsers?
Relevant documentation is also appreciated. Thanks in advance!
Just for you to briefly understand how JavaScript runs - it's always thread-safe because it runs only on a single thread.
To answer your first question, if you remove the event listener even after the event is dispatched, the function will be called, because the handler callback function ends up on the call stack. For more information I advise you to read this: javascript/browser: when does event dispatching exactly happen?
To answer your second question, removeEventListener function is synchronous, so that means that there is no possibility to run like this:
removeBrowserListener -> click -> call the event bound function
Because the browser is blocked until it finishes removing the event listener, so no clicks are registered at that time. But even with that, the answer is not that obvious, you should take a look at this question, it tackles the very same problem but from the point of view of binding the event handler, not removing it: Does addEventListener guarantee to be synchronous?
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.
I am developing a jQuery Mobile and PhoneGap app. I am using this code:
$('#contact').live('pageinit', function() {
//$.mobile.loading('show');
theme();
getData('contact/list',contactList);
//$.mobile.loading('hide');
});
When accessing page for the first time, it works good. In second attempt event is firing multiple times. I tried using bind but it doesn't work.
I think it is connected with live event. It is binded each time I initialize the page, which makes it multiple. Problem is solved when linking that way: window.location.href-it recreates DOM. Unfortunately I can't use it.
Is there any way to handle pageinit in another way?
I tried to find it earlier but with no success. Also looked at: click() firing multiple times
In theory, any event that can be bound by 'live' can be bound directly. The benefit of binding directly is that it will (iirc) overwrite the previous bound handler. As such, you would only have one handler, so it wouldn't get triggered multiple times on subsequent loading.
try something like:
$("#contact").pageInit(function() {
theme();
getData('contact/list', contactList);
});
I usually use the on() method instead of live() (which is now deprecated). I give each of my page containers an id, so on the index page it might be index, then I can bind to the event like:
$(document).on("pageinit", "#index", function() {
//do stuff here
});
Works same way for page show also.
When binding events in jquery mobile, you have to be very cautious as to ensure that they will not be bound multiple times. Navigating to a new page in jquery mobile will not "reset" the bound events as it would in more traditional navigation.
The issue your facing is most probably due to the function being bound to the event every time you access the page, meaning that the more you access the page, the more times you will get that function to be executed when you do.
In order to ensure the event is only bound once, I would recommend binding in the header of your initial page. This way, the event is bound once and for all, and the function will be run whenever this page is initiated.
You can try adding data-ajax="false" to any forms you are submitting that may be creating multiple versions of the page (firing events multiple times).
Consider the following code:
$('div').click(function(){
$(this).animate({height:100}, 500)
$(this).css({opacity:1});
});
Versus:
$('div').click(function(){
$(this).animate({height:100}, 500);
})
.click(function(){
$(this).css({opacity:1});
});
Does jQuery or JavaScript essentially "compile" the second code sample into something like the first rather than maintaining two separate event handlers? I ask about whether jQuery or JavaScript does this because I'd also be interested to know if such "compilation" is a feature of native JS or something implemented by jQuery.
It seems to me that this "compilation" is not actually done, at least not in a way that eliminates the differences between the two code samples. Using JSPerf, I compared the speed between each one and it appears that the first code sample is substantially faster.
Handlers are fired in the order they are bound and each $('div').click() binds another handler to the element in question. In your case the first one only binds 1 event handler and thus performs faster because it only fires one event. The second binds two event handlers, and thus is slower because it fires two events instead of one (more overhead).
I think they are maintained as two separate events. When triggered, they get executed in the same order they were bound.