api-designevent
Usually event listeners shouldn't outlive object that registered them.
Does it mean that event listeners should be held by weak references by default (stored in weak collections by the object listeners are registered on)?
Are there valid cases when listener should outlive its creator?
Or maybe situation like that is a mistake and it shouldn't be allowed?
At this point, it is mostly a (pretty strong) convention. That is, it will be weird if you write a library that does not follow that convention.
The Event Design Guidelines say:
DO use
objectas the type of the first parameter of the event handler, and call itsender.
However, you may note that current guidance says that you should not define your own custom delegate for events, but use EventHandler<T> instead, if you can.
As for the design, I would guess that it also promotes the reuse of event handlers, even in contexts not originally foreseen by the original designer of the event.
The Buzz Word you are looking for, which might help in your search for answers, is JavaScript Event Delegation.
There are two basic kinds of event delegation:
Component delegation: One listener for each event is registered per component on the page
Front Controller delegation: One listener for each event is registered for all components, and then attributes within the HTML are used for dynamic dispatch to functions or objects representing each component.
The kind you are questioning is the Front Controller variety.
A working example of this is a library I wrote called Oxydizr. It uses a custom HTML attribute data-actions to dispatch the handler to the proper "controller" object. While not a switch statement, it boils down to the same basic logic as you are proposing.
This layer of abstraction is useful if you have an unknown number of components that will be used on each page, and you don't want to write additional JavaScript code to wire up your UI to event listeners.
The increase in complexity is balanced out by the ease of extensibility and implementation. No more do you need to write HTML code and a bunch of JavaScript code specific to that HTML structure. Add a splash of HTML attributes and event delegation on a common root element handles calling the proper function.
a) Would it depend on the expected frequency of use?
Yes. If you have a lot of events to handle, or a lot of elements for which you need to handle interactions, the Front Controller flavor of event delegation is a good fit. The added benefit here is, if done right, adding new components is very easy.
b) would a common event such as
mousemovebe better with one approach, while input be better with another?
Actually, since the mousemove event can fire upwards of 50 times per second. To maintain a smooth experience for the user your Front Controller and handler must execute faster than 20 milliseconds. That's not much time for an interpreted language! For that reason, "spammy" events like mousemove and scroll are better handled on their own outside of event delegation of any sort. This leads into the performance implications of this pattern.
You do take a hit to performance at runtime, but gain performance at page load. The more nodes in the document tree, the more apparent the gain in page load performance becomes.
Libraries like jQuery, and native DOM API's like querySelectorAll allowing you to target elements by CSS selector have a hidden dark side: unless the browser optimizes for certain selectors, the browser basically has to iterate over every element in the document tree when getting elements by CSS selector. This is especially noticeable at page load for larger pages, and becomes even more noticeable on mobile devices with slower processors or less RAM. So, code like:
var elements = document.querySelectorAll(".foo");
for (var i = 0; i < elements.length; i++) {
elements[i].addEventListener(...);
}
Gets increasingly costly in execution time as your web application grows.
It is much faster at page load to add listeners to one element. My favorite is document.documentElement, because it references the <html> element, and exists from the moment JavaScript begins executing. No need to wait for a DOMContentLoaded event or "DOM ready" event.
You do incur a runtime performance hit for two reasons:
The event is handled after bubbling up from the source element, rather than being handled at the source element. It's been my experience that this is minimal, if not so small you can't accurately measure the impact in JavaScript.
The event delegate, be it a Front Controller or an individual component, must loop in JavaScript from the source element up the document tree for each invocation of the event just to see if it is something it can handle.
These two items do reduce performance while the user is interacting with the page. Again, it's a small reduction, so avoiding event delegation for these two reasons is a Premature Optimization.
c) if the switch approach is deemed better, what is the maximum size/complexity that the switch statement should be allowed to grow to.
The mere fact you are questioning this tells me that a switch statement is the wrong way to go about this. Don't use a switch statement. You need to annotate your HTML with some custom data-* attributes to make extending this easy, and cost zero work.
<button type="button"
data-action="confirm"
data-confirm="Are you sure?">
Delete Item?
</button>
In this naive implementation you would register a listener on a "Front Controller":
frontController.addListener("confirm", function(event) {
if (!confirm(event.target.getAttribute("data-confirm")) {
event.preventDefault();
}
});
Extending this for another component is easy:
frontController.addListener("removeItem", function(event) { ... });
The implementation of this example:
var frontController = {
listeners: {},
addListener: function(actionName, callback) {
this.listeners[actionName] = callback;
},
handleClick: function(event) {
var listeners = frontController.listeners,
action = event.target.getAttribute("data-action");
if (listeners[action]) {
listeners[action](event);
}
}
};
document.documentElement.addEventListener("click", frontController.handleClick, false);
You'll see that there is no need for a switch statement, because data embedded in the HTML document allows you to write one decision structure to handle all components. This is where you want to be if implementing the Front Controller pattern for event delegation.
So, Should I reduce event listeners by making functions more complex?
Yes, if:
No, if:
You don't care about memory leaks from removed elements that still have active event listeners.
And yes, there are times when you don't care about memory leaks. If the page isn't used for very long, a memory leak might not be a big deal. For Single Page Applications... I hope you have LOTS of RAM.
Best Answer
Why shouldn't event listeners outlive the object that registered them? It seems like you are assuming event listeners should registered by methods of controls(if we take the GUI example) - or more precisely, methods by objects of classes that inherit the GUI toolkit's controls. That's not a necessity - you could, for example, use a specialized object for registering event listeners and ditch that object afterwards.
Also, if event listeners were weakly referred, you would have to actually keep references to them even if you never use that reference. Failing to do so will make the listener be collected at a random time. So, we get a bug that is
And if avoiding that bug is not good enough incentive, here are some more:
You'll have to think of a name for each listener you create.
Some languages use static anlysis that'll generate a warning if you have a private member field that's never get written or never get read. You'll have to use have a mechanism for overriding that.
The event listener does something, and once the object that has it's strong reference is collected it'll stop doing that something. You now have something that affects the program's state and depends on the GC - which means the GC affects the concrete state of the program. And this is BAD!
Handling weak references is slower, since you have another level of indirection and since you need to check if the reference was collected. This wouldn't be a problem if having event listeners in weak references was necessary - but it isn't!