Re: Better event listeners

On Sun, Jan 6, 2013 at 7:01 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

>  Really? How would it work in a sane way with mouseenter/leave which
> behavior
> is largely about non-bubbling.
>

I'm not sure I understand the question.  For event delegation, you want
mouseenter to bubble, just like any other event.

Note that event not bubbling is only a convenience.  It's trivial to get
the same effect in an event listener without it: if(e.eventPhase !=
Event.AT_TARGET) return;

 Or perhaps you don't meant normal bubbling but you mean that if there is
> this kind of special event listener in an ancestor, such listener should be
> called even is the event doesn't bubble.
>

Firing event listeners on ancestors, after calling it on the target, is
exactly what bubbling is.

All this would mean (regardless of whether via an addEventListener flag, as
I suggested, or implicitly with another method, as Anne suggested), is that
all events would bubble, but event listeners would only be fired during the
bubble phase if either 1: the event's bubbles flag is set, or 2: the event
listener's always-bubbles flag is set.  The result would be identical for
existing code (as it needs to be, of course), since listeners with the
current APIs would always have their always-bubbles flags unset.


On Sun, Jan 6, 2013 at 7:02 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:

> Or just use capturing event listeners.
>

I think this can only be recommended as a solution if it's correct to
*always* use capture for the delegation pattern.  If you need to carefully
use capture for some cases and not for others, for the same basic pattern,
it'd be better to solve the bubbles flag problem itself.

(I don't feel too strongly about this, but if we're going to do it at all,
I think extending addEventListener to take a dictionary and make this an
option is better than adding a new entry point with subtly-different
behavior.  It's too subtle a difference, so it'll probably confuse and bite
people.)


On Mon, Jan 7, 2013 at 11:12 AM, Benoit Marchant <marchant@mac.com> wrote:

> - How about a better way when your handlers are objects and not functions?
> The big problem with functions is removing the listeners, it has to be the
> same function object and there are countless leaks today of people not
> realizing that their removeEventListener, when they thought of doing it
> actually doesn't do anything.
>

Using objects instead of functions is a pattern inherited from Java, which
is unnatural and unneeded in JavaScript.  Callbacks should simply be
functions.

As I mentioned earlier, it *seems* like it would be straightforward to add
handler objects to addEventListener, eg:

this.click_handler = elem.addEventListener("click", function(e) { });
this.click_handler.stop();

which would be equivalent to the corresponding removeEventListener call.
(I don't feel that strongly about this, either, since the patterns I'm
using for removing listeners work quite well already, but maybe it'd be
helpful for others, and we don't seem to need a new "on()" API to
accomplish it.)

- Perfornance. Event Delegation as a concept has been pushed because it's
> slow to install all these listeners upfront. Is that being worked on?
>

It'll always be slower to install a thousand separate listeners than to
install a delegate listener once.

Delegation also makes installing dynamic content using innerHTML much
simpler, since you don't need to dig into the result to find the DOM nodes
to attach listeners to.

-- 
Glenn Maynard