The old event management in which each handler for specific actions was directly attached to the target element is becoming outdated, since considerations about performance and memory saving started spreading in the developers community.
Event delegation implementations had an acceleration since jQuery updated the old fashioned .bind() and .live() methods with the new .on() method to allow delegation.
This determines a change in some seasoned approaches, where to use event delegation a rework is necessary.
I am trying to work out some best practice while keeping the coding style of my library, and looked for similar situations faced from other developers to find an answer.
Using OOP with functions as constructors, I usually have interfaces for objects creation like this:
var widget = new Widget({
timeout: 800,
expander: '.expanders'
});
with object literals given as argument, providing a clean map of names and values of the input passed. The class underlying this code could be something like the following:
var Widget = function(options) {
// some private members
var _timeout;
var _$widget;
var _$expander;
// methods
this.init = function() {
_timeout = options.timeout || 500;
_$expander = $(options.expander);
_$widget = _$expander.next();
_$expander.on('click', _toggle);
};
var _toggle = function(e) {
if (_$widget.is(':visible')) {
_$widget.hide(_timeout);
} else {
_$widget.show(_timeout);
}
};
this.init();
};
Using "private" methods gave me some benefits in terms of code readability and cleanness (only useful methods are publicly exposed to the user), beyond the small gain in performance (each scope resolution takes more time than a local variable). But when speaking about event handlers, it clashes with the event delegation paradigm.
I thought to make public the methods that I used to associate internally to the listeners in the class:
this.toggle = function(e) {
if (_$widget.is(':visible')) {
_$widget.hide(_timeout);
} else {
_$widget.show(_timeout);
}
};
then driving externally, or in another proxy class, the proper delegation with something like this:
var widget = new Widget({
expander: '.expanders'
});
$(delegationContext).on('click', '.expanders', widget.toggle);
but it did not seem to me the best approach, failing in the exposure of a non-useful method in the interface, so I tried a way to let the main class know directly all the information to delegate the event autonomously, through the interface:
var widget = new Widget({
timeout: 800,
expander: {
delegationContext: '.widgetContainer',
selector: '.expanders'
}
});
which would allow to keep on using private methods internally in the class:
var $context = $(options.expander.delegationContext);
$context.on('click', options.expander.selector, _toggle);
What are your practice and suggestions about it?
And what are the main trends of other developers you heard about as far as today?
it clashes with the event delegation paradigm.
Forget that paradigm! Don't choose it because it's "cool" and directly attaching events "is becoming outdated", choose it only when it is necessary. Event delegation is not necessary for you, nor does it speed up anything. It is not a solution you can apply - you have no problem!
You have one element and a single element-specific event handler function (every widget expander has its own function). You can already infer from your problems applying event delegation that you cannot and should not use it here. Attach the handlers directly.
Event delegation is only useful when you have a vast amount of similar elements, located consistently in the DOM with one common ancestor, that would all going to be attached the same event handler function. This is not the case with your Widget constructor that does take instance-specific options such as the expander selector.
In your current Widget class, using event delegation would clash with the single responsibility principle. In the event delegation paradigm, you would need to see the elements in the delegation context as a whole, being as homogeneous as possible. The more element-specific data and state you add, the more delegation advantages you are loosing.
If you really want to use event delegation here, I would suggest something like
var Widgets = {
init: function(delegationContext) {
$(delegationContext).on("click", ".widget-expander", function(e) {
$this = $(this);
$this.next().toggle($this.data("widget-expander-timeout") || 500);
});
},
activate: function(options) {
$(options.expander)
.addClass("widget-expander")
.data("widget-expander-timeout", options.timeout);
}
};
Here no constructors are used. You just initialise the event delegation context, and then you can add single elements to be captured by the delegation mechanism. All data is stored on the element, to be accessible from the event handler. Example:
Widgets.init('.widgetContainer');
Widgets.activate({expander: '.expanders', timeout: 800});
And what are the main trends of other developers you heard about as far as today?
Apart from that question being off-topic on StackOverflow, I can only advise you not to follow every trend someone heard about. Learn about new (or advertised or fancy) technologies, yes, but do not forget to learn about when to use them.
Related
Is there any way to get the list of all event listeners of an element on the HTML page using JavaScript on that page.
Note: I know we can see them with Chrome dev tools event listeners but I want to log/access see list using the JavaScript of the page.
Also, I know we can get them through jQuery but for that, we also have to apply the events using jQuery, but I want something that would be generic so I could also access the event listeners applied to other elements such as web components or react components.
If you really had to, a general way to do this would be to patch EventTarget.prototype.addEventListener:
const listeners = [];
const orig = EventTarget.prototype.addEventListener;
EventTarget.prototype.addEventListener = function(...args) {
if (this instanceof HTMLElement) {
listeners.push({
type: args[0],
fn: args[1],
target: this,
});
}
return orig.apply(this, args);
};
document.body.addEventListener('click', () => console.log('body clicked'));
console.log(listeners[0].fn);
click this body
To find listeners attached to an element, iterate through the listeners array and look for targets which match the element you're looking for.
To be complete, also patch removeEventListener so that items can be removed from the array when removed.
If you need to watch for listeners attached via on, then you'll have to do something similar to the above to patch the HTMLElement.prototype.onclick getter/setter, and for each listener you want to be able to detect.
That said, although you said you want a generic solution, rather than patching built-in prototypes, it'd be better to add the listeners through jQuery or through your own function.
What I did when I had a similar problem is add a data attribute when the listener was set, so I could identify it later.
At the end of the function that adds the listener:
elm.setAttribute('data-has_mask', true);
At the beginning of that same function:
if("true" == elm.getAttribute('data-has_mask')) {
return;
}
Maybe not exactly what the OP is looking for, but I was having a lot of trouble with this, and this is an obvious solution for a particular use case, and I guess it might help someone out.
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);
JQuery has great support for custom events - .bind("foo", function(e).... However what if the mechanic of triggering the event is not ready yet and has to be constructed only on those elements that have the event bound on?
For example I want a scrollin event that gets fired when an element is scrolled into a viewport. To do this, I would onscroll have to check all the elements and trigger scrollin on those that were outside the viewport and now are inside. This is not acceptable.
There are some tricks to speed it up. For example one of the plugins for this checks all the elements in "private" $.cache and does the checking only on those that have scrollin event bound.
But that's also ugly. What I need is an additional callback for the binding of the event (additional to the callback for handling) that would take care of the scroll management, that is to put the element(s) into some elementsCheckOnScrol cache array.
I'm looking for something like:
$.delegateBind("scrollin", function(jqSelection) { ... });
element.bind("scrollin", function(e) {..}); //Calls ^ after internal bind management
Edit: This would be nice api!
$.bind("bind", function(onWhat) { ... })
:-)
If I'm not misunderstanding you, you could patch the bind method like this:
(function($) {
var oldBind = $.fn.bind;
$.fn.bind = function(name) {
if(name === "scrollin") {
delegateFunction(this);
}
oldBind.apply(this, arguments);
};
})(jQuery);
What it does is checking whether a scrollin is being bound, and if so, calls your delegate function. After that it simply calls the original bind function which does all jQuery things like it does regularly.
After having added this code, you could use it like this: http://jsfiddle.net/pimvdb/g4k2G/.
function delegateFunction(selection) {
alert(selection.length);
}
$('a').bind('scrollin', function() {});
Note that this does not support object literals being passed to .bind (only (name, func)), but you could implement that as well.
I found an $.event.special API, but I don't know "how much" public it is. It is not in the docs and has been changed at least once before. http://benalman.com/news/2010/03/jquery-special-events/
I've got a thorny issue and although the answer may be obvious, I cannot see how to do what I'm trying to do.
I have created a script library for my application that uses JS prototypes and templating to dynamically instantiate DOM elements AND to wire those elements up with handlers. An example is the following:
var ppane = new AWP.iuiPanel(theObject, { title: 'Select filter(s)', idDisplay: 'block', idString: params.sender._options['title'] });
AWP.iuiPanel is a class defined as a function prototype, e.g:
AWP.iuiPanel = function() { <i'm a constructor> }
AWP.iuiPanel.prototype = { <a bunch of methods here> }
The methods inside the instance create a DOM element (in this case a floating panel) and establish event bindings for it, wire up its control elements, etc.
The advantage of going down this path is that through a single call to create a new instance of a class I can also build the associated DOM element, and once instantiated, the class methods that have been wired up will execute against the element to do things like position it relative to a target object, respond to relevant browser events, etc.
The problem I have is when I want to dispose of this construct. I can dispose the DOM element easily. But I then still have the class instance in memory with methods wired to browser events looking for the DOM element that has been disposed. I need to be able to dispose not only of the DOM element, but also of the class instance, and I cannot figure out how to do that.
How can one dispose of a function prototype once declared? This seems like it ought to be simple, but I'm finding it to be decidedly not so.
For background info, here is an example of a class as I am defining it:
This is necessarily pseudo-code(ish)...
AWP.trivialExample = function(someDomRef, someOptionSet) {
this._id = someOptionSet['name'];
this._width = someOptionSet['width'];
this._width = someOptionSet['height'];
this._domRef = someDomRef;
this._object = '';
this.constructDOM();
this.wireEvents();
}
AWP.trivialExample.prototype = {
constructDOM: function() {
// build a complex DOM element relative to a provided DOM ref using the
// desired and height. This uses a template and I won't give a precise example
// of such a template.
jQuery("#aTemplate").tmpl(someJSONData).appendTo("body");
},
positionRelative: function() {
// this function would get the location of a specific DOM ref and always maintain
// a relative position for the DOM element we just constructed
},
wireEvents: function() {
// hook up to events using JQuery (example)
jjQuery(window).resize(this.positionRelative);
}
}
The above is a trivial example that would take in a DOM object reference, and then it would dynamically construct a new DOM element and it would wire up to browser events to always maintain relative position between these two objects when the page is sized.
When I dispose of the new object, I also need to dispose of the class instance and I cannot find a simple way to do that.
All help appreciated.
Thanks;
A suggestion on the event listeners referencing a deleted DOM node:
just as you have a 'wireEvents', you should have a corresponding 'unwireEvents' in case you decide to stop using the object. addEventListener() needs to be used in conjuction with removeEventListener() in this case. You should modify your prototype to remove Event listeners when the corresponding DOM Node is 'disposed', as you say.
AWP.iuiPanel.prototype = null; // ?
According to the jQuery plugin development guides from the Internet, the common practice of developing a jQuery plugin would be:
(function($) {
$.fn.myplugin = function(options){
//...
//Plugin common characteristic
//e.g. default settings
//...
//Attach to each desired DOM element
return this.each(function(){
//Instantiation stuff...
});
}
})(jQuery);
$(document).ready(function(){
$(".someclass").myplugin();
})
It seems to me that, if the elements with class "someclass" have been attached to another plugin, once those elements are going to attach to "myplugin", they will lose the original relationship to the previously attached plugin. I'm not sure if my thinking is completely correct. Please advise if any mis-understood.
Thank you!
William Choi
An element isn't "attached" to a plug-in. A plug-in just adds further methods to the jQuery wrapper for a matched set of elements. So just as the jQuery wrapper has parent and find, it also has the plug-in's myplugin method. These can all coexist as long as there are no naming conflicts.
It's true that if two different plug-ins both try to change something about the elements that cannot be two things at once (a plug-in that changes the foreground color to "blue" and another changing the foreground color to "red"), then they'd collide if you called both of the two plug-ins methods on the same element set. But that's just like two calls to css.
In particular, remember that there can be multiple event handlers assigned to the same event on the same element, so plug-ins that hook events need not necessarily conflict with one another (unless one of them stops the event during handling).
Here's an example of two plug-ins that act on the matched set of elements, but in non-conflicting ways:
plugin1.js:
(function($) {
$.fn.foo = function() {
this.css("background-color", "#b00");
return this;
};
})(jQuery);
plugin2.js:
(function($) {
$.fn.bar = function() {
this.css("color", "white");
return this;
};
})(jQuery);
Usage:
$("#target").foo();
$("#target").bar();
or even
$("#target").foo().bar();
Live example
Now, if both the foo and bar plug-ins tried to set the foreground color, the one called later would win.
Here's an example of a pair of plug-ins that both want to handle the click event, but do so in a cooperative way:
plugin1.js:
(function($) {
$.fn.foo = function() {
this.click(function() {
$("<p>Click received by foo</p>").appendTo(document.body);
});
return this;
};
})(jQuery);
plugin2.js:
(function($) {
$.fn.bar = function() {
this.click(function() {
$("<p>Click received by bar</p>").appendTo(document.body);
});
return this;
};
})(jQuery);
Usage:
jQuery(function($) {
$("#target").foo().bar();
});
Live example
There's no magical relationship going on. There's no central registry or snap-ins that "belong" to any one element or to any one plug-in.
Javascript objects are just hacked-up functions; when you "attach a plugin" to an element, you're just calling some third-party library function that does something to that element, and possibly stores some internal data to assist with its animation throughout the session.
So there is nothing legally stopping you from "attaching" multiple plug-ins to the same element, though of course whether they'll be logically compatible is quite another question.