Re: Better event listeners

On Sat, Jan 5, 2013 at 6:26 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> We discussed this a long time ago. Lets try again. I think ideally we
> introduce something like http://api.jquery.com/on/ Lets not focus on
> the API for now, but on what we want to accomplish.
>
> Type and callback are the basics. Selector-based filtering of
> event.currentTarget should be there, but optional. I'm not sure about
> the data feature, Yehuda?
>

Event delegation wants filtering on event.target, not currentTarget.  Do
you mean that it should support filtering on currentTarget in addition to
target (in which case: what for?)


> Should we make all events bubble for the purposes of this new
> registration mechanism? I actually thought Jonas said jQuery did that
> at some point, but the jQuery documentation does not suggest it does.
>

That depends on the API.  I don't think we necessarily need a new method;
we can override addEventListener straightforwardly, when the third
parameter is a dictionary instead of a boolean:

element.addEventListener("click", handler, {
    // Only fire the handler if event.target matches this selector at
dispatch time.
    filter: ".click",

    // If this is a non-capturing listener, fire this event during the
bubble phase even if the event's bubbles
    // flag is false.
    alwaysBubble: true,

    // If true, this is a capturing listener.
    capture: true,
});

This allows overriding the annoying bubbles flag, but without it being a
subtle, implicit difference between APIs.  It does mean event delegation
takes a little more typing, but it's not bad:

container.addEventListener("focus", handler, { filter: "input",
alwaysBubble: true });

The "handler = container.addEventListener(); handler.stop();" pattern could
probably be supported here, too, unless for some reason making
addEventListener return a value actually has web compat problems.

Should we have event-data-based filtering? E.g. developers could
> register to only get key events for the WASD keys. Optimization for
> developers could be that they get to have one callback per key,
> optimization for browsers and speed of the application would be that
> less events need to be processed ideally leading to a better user
> experience.
>

This is something I hear a lot but have never seen cause any real-world
issue.  Event dispatch is fast, and keypresses are slow.

It seems capture-listeners are not needed. At least for now.
>

Again, they're absolutely needed; it's a basic, critical feature of the
event model.  It's also just a flag on the handler, so I don't know why
this is being suggested.


On Sat, Jan 5, 2013 at 6:52 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:

>  Should we make all events bubble for the purposes of this new
>> registration mechanism?
>>
> Why?


You always want events to bubble for event delegation.

Also, how should it work? Should the selector matching run when
> event target chain is created or when the event is actually handled.
> If the DOM is modified while event is being dispatched, and some parts of
> the event target chain
> isn't anymore in the tree, selector based filtering may cause unexpected
> results.


I'd perform the check immediately before invoking the event listener.  It
guarantees that the filter always matches at the time the listener is
actually invoked.  Precalculating the filter would also be weird for the
case where event listeners are added during event dispatch, after the
precalculation has already happened.

-- 
Glenn Maynard