Disclaimer: Title is not super exact.
I have a service with a public method openCamera that calls a library in the global object and attaches eventlisteners to its HTML elements. When I call this service method from the HTML elements events, it works fine, but not when I call it via events attached to the window element. An example below:
class ImageService {
public static AttachEventOnce = false;
public openCamera() {
let camera = new JpegCamera('myContainer');
// captureBtn and videoBox are HTML elements generated from the library once instantiated
camera.captureBtn.addEventListener('click', () => this.openCamera()); // this works fine
camera.videoBox.addEventListener('resize', () => this.openCamera()); // doesn't enter here ie not calling it
if (!ImageService.AttachEventOnce) {
var that = this;
window.addEventListener('resize', () => that.openCamera()); // the buttons stop working
ImageService.AttachEventOnce = true;
}
};
}
The logic have been somewhat minified but more or less the same. I just want to call the service method again and again when window is resized. I don't care where I attach the listener (HTML element generated from the library or window).
My take: The window seem to retain the older object reference too as well as other listeners for other buttons which I think is causing the issue.
The window seem to retain the older object reference too as well as other listerers for other buttons which I think is causing the issue.
Correct — not because it's on window, but because you're using an arrow function and only hooking the event once, on the first instance where openCamera is called. So it doesn't matter whether that instance is discarded by everything else, it's the only instance that will receive that resize event. (There's also no reason for the var that = this; thing and then using that inside the function; arrow functions close over this like they do variables, so it does exactly what just using this within the function would do.)
It's not clear why you're doing that as opposed to hooking the event in an instance-specific way like you are the other events. If you remove the logic hooking it only once, you'll get the per-instance behavior.
Separately: It's odd to be attaching new event handlers every time the event occurs. You'll very quickly have them stacking up. The first time (say) you receive a click, you'll add a second click handler; the next time you receive a click, you'll receive two of them (one for each handler), and add two more handlers; and so on, doubling every time. This is bad enough with clicks, but disasterous with resize as there are a lot of resize events triggered when the window is being resized.
Related
Commuity,
I have a problem with a specific piece of code I am writing currently. The problem is that i want to delegate the animations. (E.g. I have 3 objects, the first is animated, after that the second and after that the third)
The point is I am trying to make it modular so i can't hard code anything in there.
On start we have following situation:
parentDiv is supposed to contain the objects you want to "fadeIn"
prevDiv is the object which was "fadedIn" recently
onclickDisabled is a class to remove "click" events temporarily
fadeInAnim is the class to trigger needed animation
function prepareChildrenForFadeInAnimation(parentDiv, prevId){
var object = 0;
parentDiv.children().each(function(){
$(this).addClass('onclickDisabled');
addAnimationAfterAnimationEnd($(this)[object].id, prevId);
prevId = $(this)[object].id;
});
}
function addAnimationAfterAnimationEnd(currentSelection, prevSelection){
document.getElementById(prevSelection).addEventListener("webkitAnimationEnd", triggerNextAnimation(currentSelection, prevSelection));
document.getElementById(prevSelection).addEventListener("animationend", triggerNextAnimation(currentSelection, prevSelection));
}
function triggerNextAnimation(selection, prevSelection){
selection = $('#'+selection);
selection.addClass('fadeInAnim');
prevSelection = $('#'+prevSelection);
prevSelection.removeClass('onclickDisabled');
}
I have a feeling that in addAnimationAfterAnimationEnd() the function triggerNextAnimation() is fired, but I don't have a clue how to prevent this since I need to submit parameters (or do I?).
If one of you guys could help me out I would be overjoyed!
PS: I am using "Chrome" and "Firefox" for testing.
The JavaScript at Question is calling the function triggerNextAnimation(currentSelection, prevSelection) immediately instead of referencing the function to be called when event is dispatche at the object.
You can use Function.prototype.bind() or $.proxy() to reference the function which should be called when the event is dispatched and with this set to a specific object and pass parameters.
Also, it is not necessary to use vendor prefix if you are already using jQuery. You can use .on("animationend")
document.getElementById(prevSelection).addEventListener("animationend",
triggerNextAnimation.bind(null, currentSelection, prevSelection))
The problem was that the function, which was supposed to trigger after certain animation, was simply executed.
document.getElementById(prevSelection).addEventListener("animationend",
triggerNextAnimation.bind(null, currentSelection, prevSelection));
The code above solves this problem. "Function.bind()" enables me to specificaly call the function after an event
In ArcGIS JS API I need to trigger a method of my class when the processing after an extent change is complete. I didn't find any special event for this. extent-change triggers too early, when the data are not loaded yet. update-end is triggered also by the function I want to call, making an endless loop. So what I need is to link the two events together, the second one just once. But how?
Most of my events look like this:
this.events.push(on(this.map, "extent-change", lang.hitch(this, this._foo)));
This is not suitable for event linking, so I need to make the linked event some other way. What I've tried:
_foo: function () {
function fooEvent() {
this._bar();
dojo.disconnect(updateHandle);
}
var updateHandle = dojo.connect(map, "onUpdateEnd", fooEvent());
}
_bar is the method I want to run on the end of the extent change. However, this in the event handler means something else, not the class containing the function. I also tried the classname I declared in the declare statement, but with no luck.
_foo() and _bar() are in the same class (let's call it "foobar/baz"). However, inside of the fooEvent() is not its subclass as I hoped - when I try to use this.inherited within it, it's undefined. Another way I try is to add event argument to the handler, but it's undefined as well. So unless there is some better way, I need to understand how to get the object of "foobar/baz" class.
Another way I tried was to use lang.hitch once more, in one of the following ways:
//through the cluster event
var updateHandle = dojo.connect(map, "onUpdateEnd", lang.hitch(this, clusterEvent));
//or directly calling _bar()
var updateHandle = dojo.connect(map, "onUpdateEnd", { langh:lang.hitch(this, this._bar), disc:dojo.disconnect(updateHandle)});
//or through on, leaving a rouge event listener
dojo.on(map, "onUpdateEnd", lang.hitch(this, this._bar));
None of them returns any clear error and though the _bar() method seemed to work for some time, it doesn't work now - this is true for all three of the previous. I don't understand what these listeners do.
I solved this issue by flattening the event listeners. First, I made a flag _reloadFlag, initialized in the constructor as false and then changed to true whenever I want to call _bar, like in _foo. _bar now starts with a test of _reloadFlag either setting it to false or returning nothing. The event listeners now look like this:
this.events.push(on(this.map, "extent-change", lang.hitch(this, this._foo)));
this.events.push(on(this.map, "update-end", lang.hitch(this, this._bar)));
I want to know if I add an event listener to a button, do I have to remove it on unload? Would pressing the 'back' button automatic removes everything current page elements in which I don't need to worry about memory leaks?
(function () {
"use strict";
ui.Pages.define("/pages/registraton/registraton.html",{
ready: function (element, options) {
document.getElementById("submitRegister").addEventListener(
"click", postRegistration , false);
},
unload: function () {
document.getElementById("submitRegister").removeEventListener(
"click", postRegistration, false);
}
});...
Thanks in advance.
You need to worry about memory leaks in the single-page navigation model that the WinJS.Navigation namespace promotes.
The model you've set up -- where by you implement unload -- is definitely the right approach. How complex & deep you want to get depends on the complexity of your application. Specifically, if you have multiple controls, with multiple manual event handlers you may want to create a set of helpers to enable you to clean up those handlers in one swoop. This may be as simple as pushing element, event name, and the handler instance into an array when when leaving that page and destroying/removing it from the DOM, you can just burn through the array removing the items that need to be cleaned up.
Note that you need to only need to explicitly clean up the case where the handler, and the DOM object have different life times. If they go away together -- e.g. a control attached to a DOM element in the page then you don't have to clean up the everything explicitly. The Garbage Collector will eventually clean it up. If you are a particularly memory heavy application, you may get some wins here by removing the listeners more aggressively.
There are some other things to remember:
This also applies to pure javascript objects that implement the addEventListener contract i.e. the list view
Don't use attachEvent -- it's going to cause unbreakable cycles due to it's old implementation under the covers. It is actually a deprecated API, so shouldn't be used anyway
Be wary when you supply event handlers where you've bound the this pointer, when your trying to unbind them. E.g.
Example:
var element = getInterestingElement();
element.addEventListener("click", this.handleClick.bind(this));
If you try to detach the event, you're lost -- the return valud from the .bind() is lost in the wind, and you'll never be able to unhook it:
var element = getInterestingElement();
element.removeEventListener("click", this.handleClick); // Won't remove the listener
element.removeEventListener("click", this.handleClick.bind(this)); // Won't remove, since it's a different function object
The best solution here is to either monkey patch handleClick before attaching it:
this.handleClick = this.handleClick.bind(this);
Or store it away for later use:
this.handlerClickToCleanup = this.handleClick.bind(this);
element.addEventListener("click", this.handleClickToCleanup);
I have a Javascript plugin that searches the DOM for any elements starting with the class name "tracking" and adds a click event listener (or another type of listener, if specified) to that element. The idea is that every time that event occurs on that element, that it runs a Javascript function that sends data to our traffic servers. Here's what the code looks like:
// Once the page is completed loaded
window.mmload(function() {
// Get the container object
obj = document.getElementById(name);
if ( obj.length < 0 )
throw ("The Id passed into the tracker does not exist ("+name+")");
// Find all the elements belonging to the tracking class
var trackingClass = new RegExp( /tracking\[[a-zA-Z0-9\.\-_]+\]/g );
var myElements = getElementsByRegex( trackingClass, obj );
//For each of those elements...
for( var i in myElements ) {
var elm = myElements[i];
var method = elm.className.match( /tracking\[[a-zA-Z0-9\.\-_]+\]/ )[0].split('[')[1].replace(']','').split('.')[2];
method = typeof( method ) == 'undefined' ? 'click' : method;
// Add a click event listener
myElements[i].addEventListener( method, function(e){
// Get the element, the link (if any), and the args of the event
var link = elm.getAttribute('href') == null ? "" : elm.getAttribute('href');
var args = elm.className.match( /tracking\[[a-zA-Z0-9\.\-_]+\]/ )[0].split('[')[1].replace(']','').split('.');
// If a link existed, pause it, for now
if ( link != '' )
e.preventDefault();
// Track the event
eventTracker( args[0], args[1], ( method == 'click' ? 'redirect' : 'default' ), link );
return false;
}, true);
}
});
Right now I've got this chuck of code running once the window has completely loaded (window.mmload() is a function I made for appending window.onload events). However, there maybe times when I need to run this function again because I added new elements to the DOM via Javascript with this class name and I want to track them too.
My initial solution was to run this function using setInterval to check the DOM every few milliseconds or second or whatever makes the most sense. However, I was worried if I took this approach that it might slow down the website, especially since this is running on a mobile website for smartphones. I'm not sure what kind of a performance hit I might take if I'm searching to DOM every so often.
The other approach I had in mind was to simply call the function after adding traceable elements to the DOM. This is probably the most efficient way of handling it. However, the people that I'm working with, granted very smart individuals, are Web Designers who don't often think about nor understand very well code. So the simpler I can make this, the better. That's why I liked the setInterval approach because nothing additional would be required of them. But if it noticeably slows down the site, I might have to take the other approach.
You should consider even delegation.
You just add one event listener to the document root and check the class of the element the event originated from (event.target). If you want to include also clicks from descendants, you'd have to traverse the DOM up form the target and check whether any of the ancestors contains the class.
I see two main advantages:
It works for newly generated elements without any extra steps (so the other developers don't have to do anything special).
It adds only one event handler instead of potentially many, which saves memory.
Disadvantages:
If other event handlers are registered along the path and they prevent the event from bubbling up, you cannot register this event.
A bit more information:
An event handler gets an event object as first argument. This object has several properties, among others, which element the event originated form.
E.g. to get the target element:
var element = event.target || event.srcElement;
This will be a DOM element and you can access the classes via element.className.
So your event listener could look like this (note that IE uses another method to attach event listeners and the event object is not passed but available via window.event):
function handler(event) {
event = event || window.event;
var target = event.target || event.srcElement;
if(target.className.match(/tracking\[[a-zA-Z0-9\.\-_]+\]/g) {
// do your stuff
}
}
if(document.addEventListener) {
document.addEventListener('click', handler, false);
}
else {
document.attachEvent('onclick', handler);
}
But as I said, this would miss events that are prevented from bubbling up. At least in the browsers following the W3C model (so not IE), you can handle the events in the capture phase by setting the last parameter to true:
document.addEventListener('click', handler, true);
If you can live without IE, then there is a change event which you can hook into for the window/document/dom element. Simply hook into the event at the document level, and it'd fire anytime something's changed in the page (stuff inserted, deleted, changed). I believe the event's context contains what got changed, so it should be fairly trivial to find any new trackable elements and attach your spy code to it.
A third option would be to write a method for manipulating the innerHTML of an element. At the end of that method simply call your function that refreshes everything.
example:
var setHtml = function(element, newHtml){
element.innerhtml = newHtml;
yourRefreshFunction();
}
So obviously this requires that you have your web developers user this method to update the dom. And you'll have to do it for anything that is more complicated than simple html edits. But that gives you the idea.
Hope that helps!
I have a web page with DIVs with a mouseover handler that is intended to show a pop-up information bubble. I don't want more than one info bubble to be visible at a time. But when the user moves the mouse rapidly over two items, I sometimes get two bubbles. This should not happen, because the code for showing a pop-up cancels the previous pop-up.
If this were a multi-threaded system then the problem would be obvious: there are two threads trying to show a pop-up, and they both cancel existing pop-ups then pop up their own pop-ups. But I assumed JavaScript is always run single-threaded, which would prevent this. Am I wrong? Are event handlers running asynchronously, in which case I need synchronized access to shared data, or should I instead be looking for bugs in the library code for cancelling pop-ups?
Edited to add:
The library in question is SIMILE Timeline and its Ajax library;
The event handler does call SimileAjax.DOM.cancelEvent(domEvt), which I assume based on the name cancels the bubbling of events;
Just to make thing s more complicated, what I am actually doing is starting a timeout that if not cancelled by a moustout shows the pop-up, this being intended to prevent pop-ups flickering annoyingly but annoyingly having the reverse effect.
I'll have another poke at it and see if I can work out where I am going wrong. :-)
Yes, Javascript is single-threaded. Even with browsers like Google Chrome, there is one thread per tab.
Without knowing how you are trying to cancel one pop-up from another, it's hard to say what is the cause of your problem.
If your DIVs are nested within one another, you may have an event propagation issue.
I don't know the library you are using, but if you are only trying to display one tooltip of somesort at a time... use a flyweight object. Basically a flyweight is something that is made once and used over and over again. Think of a singleton class. So you call a class statically that when first invoked automatically creates an object of itself and stores it. One this happens every static all references the same object and because of this you don't get multiple tooltips or conflicts.
I use ExtJS and they do tooltips, and message boxes as both flyweight elements. I'm hoping that your frameworks had flyweight elements as well, otherwise you will just have to make your own singleton and call it.
It is single threaded in browsers. Event handlers are running asynchroniously in one thread, non blocking doesn't allways mean multithreaded. Is one of your divs a child of the other? Because events spread like bubbles in the dom tree from child to parent.
Similar to what pkaeding said, it's hard to guess the problem without seeing your markup and script; however, I'd venture to say that you're not properly stopping the event propagation and/or you're not properly hiding the existing element. I don't know if you're using a framework or not, but here's a possible solution using Prototype:
// maintain a reference to the active div bubble
this.oActiveDivBubble = null;
// event handler for the first div
$('exampleDiv1').observe('mouseover', function(evt) {
evt.stop();
if(this.oActiveDivBubble ) {
this.oActiveDivBubble .hide();
}
this.oActiveDivBubble = $('exampleDiv1Bubble');
this.oActiveDivBubble .show();
}.bind(this));
// event handler for the second div
$('exampleDiv2').observe('mouseover'), function(evt) {
evt.stop();
if(this.oActiveDivBubble) {
this.oActiveDivBubble.hide();
}
this.oActiveDivBubble = $('exampleDiv2Bubble');
this.oActiveDivBubble .show();
}.bind(this));
Of course, this could be generalized further by getting all of the elements with, say, the same class, iterating through them, and applying the same event handling function to each of them.
Either way, hopefully this helps.
FYI: As of Firefox 3 there is a change pretty much relevant to this discussion: execution threads causing synchronous XMLHttpRequest requests get detached (this is why the interface doesn't freeze there during synchronous requests) and the execution continues. Upon synchronous request completion, its thread continues as well. They won't be executed at the same time, however relying on the assumption that single thread stops while a synchronous procedure (request) happening is not applicable any more.
It could be that the display isn't refreshing fast enough. Depending on the JS library you are using, you might be able to put a tiny delay on the pop-up "show" effect.
Here's the working version, more or less. When creating items we attach a mouseover event:
var self = this;
SimileAjax.DOM.registerEvent(labelElmtData.elmt, "mouseover", function (elt, domEvt, target) {
return self._onHover(labelElmtData.elmt, domEvt, evt);
});
This calls a function that sets a timeout (pre-existing timeouts for a different item is cancelled first):
MyPlan.EventPainter.prototype._onHover = function(target, domEvt, evt) {
... calculate x and y ...
domEvt.cancelBubble = true;
SimileAjax.DOM.cancelEvent(domEvt);
this._futureShowBubble(x, y, evt);
return false;
}
MyPlan.EventPainter.prototype._futureShowBubble = function (x, y, evt) {
if (this._futurePopup) {
if (evt.getID() == this._futurePopup.evt.getID()) {
return;
} else {
/* We had queued a different event's pop-up; this must now be cancelled. */
window.clearTimeout(this._futurePopup.timeoutID);
}
}
this._futurePopup = {
x: x,
y: y,
evt: evt
};
var self = this;
this._futurePopup.timeoutID = window.setTimeout(function () {
self._onTimeout();
}, this._popupTimeout);
}
This in turn shows the bubble if it fires before being cancelled:
MyPlan.EventPainter.prototype._onTimeout = function () {
this._showBubble(this._futurePopup.x, this._futurePopup.y, this._futurePopup.evt);
};
MyPlan.EventPainter.prototype._showBubble = function(x, y, evt) {
if (this._futurePopup) {
window.clearTimeout(this._futurePopup.timeoutID);
this._futurePopup = null;
}
...
SimileAjax.WindowManager.cancelPopups();
SimileAjax.Graphics.createBubbleForContentAndPoint(...);
};
This seems to work now I have set the timeout to 200 ms rather than 100 ms. Not sure why too short a timeout causes the multi-bubble thing to happen, but I guess queuing of window events or something might still be happening while the newly added elements are being laid out.