Better event listeners

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Jake Verbaten
that element.on(new MyClass) sounds like the kind of thing you would find an opinionated OOP MVC framework.

It's probably going to unsuitable to add something like that to the DOM as those opinionated frameworks change their mind about "what is best" every year.

also note that 

var c = bindAll(MyClass())
target.on("click", c.onclick)
...

solves your problem.


On Wed, Jan 9, 2013 at 6:35 PM, Jonas Sicking <[hidden email]> wrote:
On Jan 5, 2013 4:28 AM, "Anne van Kesteren" <[hidden email]> 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?

What I understand many people to do is to attach an event listener at
the root of a subtree (often the document) and then filter based on if
the clicked (or whatever the event represents) matches a given
selector. The effect of that is similar to if you had attached an
event listener to all elements matching a given selector, and keep
registering and unregistering as elements are added and removed.

In order for that to work you need to do selector-based filtering of
event.target, not event.currentTarget.

> 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.

The pattern described above only works on events that bubble. I think
we've received pressure every now and then from authors to make
certain events bubble just so that they can use that pattern. Note
that this is also useful if you aren't doing selector-based matching,
but rather want to be notified any time some particular event happens.

In general I think the original DOM specs got it right when they
created the capture, target and bubble phases. And when they realized
that for some events you only want to listen to the target, and for
some you want to listen both on target and on ancestors.

However I think they used the wrong solution by making the distinction
solely based on what the type of the event is. While the type of the
event certainly is a good indicator for if an event handler is most
likely going to want to listen only to events fired at a particular
node, or on all events fired on a subtree, there are exceptions.

Attaching event handlers in a sub tree and then doing filtering based
on selectors or node names to only catch events fired at certain
targets, seems like a good example of such an exception.

It has been suggested (both here and elsewhere, including by me) that
you can use capturing event listeners to implement a
catch-all-in-subtree listener. However I've been convinced that this
isn't a good solution.

Capturing event handlers were created to permit a generic top-level
handlers which override event handlers on descendants, typically on
the target itself. By using .preventDefault() and .defaultPrevented
the capturing event handler can signal to event handlers on the target
that it already has handled the event and that no further action
should be taken.

Bubbling event handlers allow the opposite. I.e. a generic top-level
handler which only take action if event handlers on descendants hasn't
already handled the event.

By telling people that they have to use capturing handlers we make
this impossible. Generic handlers on ancestors would always execute
before more specific handlers on the target.

So I don't think that we want to force people to use capturing
listeners any time they want to catch all events targeted at a
particular subtree.

Instead we should make it possible to at the time of registration,
select whether the listener wants to listen to during the bubbling,
target or capture phase. And maybe allow multiple phases. We could
certainly have defaults based on the event type, but I think it should
be possible to override that default.


On the subject of things that we want to accomplish with this new API:

One thing not mentioned in your original email which I *think* might
be nice to accomplish would be to allow more OOP-style use of events,
but with JS flavor. In particular, what a lot of people do right now
is to write code like:

foo.addEventListener("click", myHandlerFunction);
function myHandlerFunction(event) { ... };

Or

foo.addEventListener("click", function(event) { ... });

In other words, they pass a function as the event handler.

Unfortunately javascript doesn't let you do

foo.addEventListener("click", object.clickhandler);

If you do that, the "this" object when clickhandler is called won't be
|object| but rather |foo|. Instead people end up doing

foo.addEventListener("click", object.clickhandler.bind(object));

which is pretty verbose.

It would be nice if it was possible to automatically register a set of
functions on an object to as listener for a set of events. And that
the functions were dispatched such that the 'this' object was the
"correct" object. In other words, that you could actually use OOP
style for your code. Especially since a lot of large JS codebases use
OOP style to a large extent. Which shouldn't be surprising given that
JS is, you know, a OOP based language :)

There are many ways to accomplish this, and I don't want to make a
specific proposal here since this thread is about gathering
requirements not proposals. But I also don't want people to dismiss
this idea just because they don't like specific ways to accomplish
this.

So here are a couple of potential solutions:

function MyClass(state) {
  this._state = state;
}
MyClass.prototype = {
  onclick: function(event) { ... },
  ondblclick: function(event) { ... },
  somehelperfunction: function(x) { ... }
}
element.on(["click", "dblclick"], new MyClass(1234));


or


function MyClass(state) {
  this._state = state;
}
MyClass.prototype = {
  onclick: function(event) { ... },
  ondblclick: function(event) { ... },
  somehelperfunction: function(x) { ... }
}
element.on(new MyClass(1234));
// we enumerate all properties of the object and add event listener
based on property names starting with "on".


or


function MyClass(state) {
  this._state = state;
}
MyClass.prototype = {
  onclick: function(event) { ... },
  myDoubleClickHandler: function(event) { ... },
  somehelperfunction: function(x) { ... }
}
element.on({ click: "onclick", dblclick: "myDoubleClickHandler" }, new
MyClass(1234));


/ Jonas


Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Anne van Kesteren-4
In reply to this post by Domenic Denicola
On Wed, Jan 9, 2013 at 3:27 AM, Domenic Denicola
<[hidden email]> wrote:
> What about just... "off"?

Well that is the pattern some of the registration mechanism use,
including addEventListener() today. However, it requires keeping track
of all arguments passed. Or at least those that determine the "key"
for what an event listener is (currently that would be type, callback,
capture flag).

It's already not that convenient to keep track of the callback, so
maybe instead we should use a mechanism similar to setInternal() and
friends. They return an integer you can later pass to a remove method.

That doesn't seem quite as elegant as returning a function pointer
however as per Jake's proposal. (Returning an object here with a
method seems overkill to me.)


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Anne van Kesteren-4
In reply to this post by Domenic Denicola
On Wed, Jan 9, 2013 at 4:50 AM, Brad Pettit <[hidden email]> wrote:
> As EventListeners are unordered, ...

They are ordered actually, see http://dom.spec.whatwg.org/


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Anne van Kesteren-4
In reply to this post by Jonas Sicking-2
On Thu, Jan 10, 2013 at 3:35 AM, Jonas Sicking <[hidden email]> wrote:
> In order for that to work you need to do selector-based filtering of
> event.target, not event.currentTarget.

Yeah, my bad.


> Instead we should make it possible to at the time of registration,
> select whether the listener wants to listen to during the bubbling,
> target or capture phase. And maybe allow multiple phases. We could
> certainly have defaults based on the event type, but I think it should
> be possible to override that default.

Agreed.


> foo.addEventListener("click", object.clickhandler.bind(object));
>
> which is pretty verbose.

We discussed this in depth before when discussing the approach for
callbacks. We decided bind() was exactly the kind of feature that can
be used for this and maybe future editions of JavaScript should make
it easier to use, but that we would not try to work around it.


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Domenic Denicola
In reply to this post by Anne van Kesteren-4


On Jan 10, 2013, at 7:39, "Anne van Kesteren" <[hidden email]> wrote:

> On Wed, Jan 9, 2013 at 3:27 AM, Domenic Denicola
> <[hidden email]> wrote:
>> What about just... "off"?
>
> Well that is the pattern some of the registration mechanism use,
> including addEventListener() today. However, it requires keeping track
> of all arguments passed. Or at least those that determine the "key"
> for what an event listener is (currently that would be type, callback,
> capture flag).
>
> It's already not that convenient to keep track of the callback, so
> maybe instead we should use a mechanism similar to setInternal() and
> friends. They return an integer you can later pass to a remove method.
>
> That doesn't seem quite as elegant as returning a function pointer
> however as per Jake's proposal. (Returning an object here with a
> method seems overkill to me.)
>
>
> --
> http://annevankesteren.nl/
>


I meant that, if an object with methods were returned, the method should be named "off" as opposed to "cancel" or "stop" etc. Agreed that a function instead of an object is more elegant, however.

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Brandon Wallace
> I meant that, if an object with methods were returned, the method should be named "off" as opposed to "cancel" or "stop" etc. Agreed that a function instead of an object is more elegant, however.

I believe it has been mentioned that an object leaves the door open for future enhancements.  Returning only a function limits your options for future enhancements.

--
Brandon
Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Anne van Kesteren-4
On Thu, Jan 10, 2013 at 2:38 PM,  <[hidden email]> wrote:
> I believe it has been mentioned that an object leaves the door open for future enhancements.  Returning only a function limits your options for future enhancements.

Given that there's ample precedence for such APIs in setInterval() and
such I'm not too worried about that. Enhancements will always be
possible one way or another. Memory usage and added complexity are
also considerations.


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Robin Berjon-6
In reply to this post by Brandon Wallace
On 10/01/2013 14:38 , [hidden email] wrote:
>> I meant that, if an object with methods were returned, the method
>> should be named "off" as opposed to "cancel" or "stop" etc. Agreed
>> that a function instead of an object is more elegant, however.
>
> I believe it has been mentioned that an object leaves the door open
> for future enhancements.  Returning only a function limits your
> options for future enhancements.

Actually, just because it's a function doesn't mean it can't be extended:

var obj = function () { console.log("stop"); };
obj.start = function () { console.log("start"); };
obj();
obj.start();

Whether that's elegant is another question.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Rick Waldron
In reply to this post by Domenic Denicola
+1 :D


On Tue, Jan 8, 2013 at 9:27 PM, Domenic Denicola <[hidden email]> wrote:
What about just... "off"?

> -----Original Message-----
> From: Brandon Wallace [mailto:[hidden email]]
> Sent: Tuesday, January 8, 2013 21:20
> To: Jake Verbaten; Glenn Maynard
> Cc: Anne van Kesteren; [hidden email]
> Subject: Re: Better event listeners
>
> An object with a "dispose" is a common choice.  knockoutjs & Reactive
> Extensions both use it to unsubscribe.  The name is not terribly verbose and
> has a general enough meaning that it can be applied to many different
> concepts, including stop listening to an event listener.
>
> If you choose a method name that is "common" with other patterns in use,
> then it allows for easier interoperability.  For example, if you indeed chose to
> return a "Disposable", then developers can leverage existing libraries to help
> manage their event listeners.  Here's a simplistic example that makes use of
> Rx.CompositeDisposable* to manage subscriptions to some knockout
> observables, rx observables, and event handlers:
>
> var allMySubscriptions = new Rx.CompositeDisposable();
> allMySubscriptions.add(someKnockoutObservable.subscribe(function (value)
> { ... })); allMySubscriptions.add(someRxObservable.subscribe(function (value)
> { ... }, function (error) { ... }, function () { ... }));
> allMySubscriptions.add(addEventListener("click", function (ev) { ... }));
>
> ...elsewhere...
> allMySubscriptions.dispose(); // code making this call doesn't even need to
> know what is being disposed.
>
> Works because all involved APIs return an object that has a "dispose" method
> to end the subscription.
>
> * https://github.com/Reactive-
> Extensions/RxJS/blob/master/src/core/disposables/compositedisposable.js
>
> Brandon
>
>
>
> ________________________________
> From: Jake Verbaten <[hidden email]>
> To: Glenn Maynard <[hidden email]>
> Cc: Anne van Kesteren <[hidden email]>; "[hidden email]" <www-
> [hidden email]>
> Sent: Tuesday, January 8, 2013 5:38 PM
> Subject: Re: Better event listeners
>
>
> using an object also allows for future scope creep. Returning a function makes
> the API simple and reduces complexity.
>
>
> However almost none of the existing host APIs are higher order functions (I
> can't think of a single API that returns a function) so it probably doesn't fit
> with the style.
>
> However returning an object with a method stop is ambigious, returning an
> object with a method removeEventListener is verbose. I guess an object with a
> cancel method would make sense.
>
>
>
> On Tue, Jan 8, 2013 at 3:32 PM, Glenn Maynard <[hidden email]> wrote:
>
> On Tue, Jan 8, 2013 at 5:23 AM, Anne van Kesteren <[hidden email]>
> wrote:
> >
> >On Mon, Jan 7, 2013 at 6:18 PM, Jake Verbaten <[hidden email]>
> wrote:
> >>> Emphasis being on that `.on(...)` returns some kind of token that
> >>> can be used to remove the listener so we don't have to keep a
> >>> reference to the listener ourself somewhere.
> >>
> >>I think that makes a lot of sense. I like the idea of just returning a
> >>function reference.
> >>
> >
> >Returning an object with a method is a more common pattern on the
> platform.  It also allows adding related features in the future without
> contortions (eg. Prototype's also has start(), to re-add the listener).
> >--
> >Glenn Maynard
> >
> >
>


Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Jake Verbaten
In reply to this post by Brandon Wallace

Putting properties on a function is valid. There's plenty of room for future enhancements.

On Jan 10, 2013 5:38 AM, <[hidden email]> wrote:
> I meant that, if an object with methods were returned, the method should be named "off" as opposed to "cancel" or "stop" etc. Agreed that a function instead of an object is more elegant, however.

I believe it has been mentioned that an object leaves the door open for future enhancements.  Returning only a function limits your options for future enhancements.

--
Brandon
Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

James Graham-7
On 01/10/2013 08:06 PM, Jake Verbaten wrote:
> Putting properties on a function is valid. There's plenty of room for
> future enhancements.

It's valid but ugly as hell.

I don't see why we want to artificially paint ourselves into a corner here.

is
var evt = elem.on("click", function() {}, "button");
[...]
evt.detach();

so much worse than

var detach = elem.on("click", function() {}, "button");
[...]
detach();

That we are prepared to risk future headaches because we didn't allow
for the possibility of future additions to this part of the platform?

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Anne van Kesteren-4
On Fri, Jan 11, 2013 at 1:53 PM, James Graham <[hidden email]> wrote:
> That we are prepared to risk future headaches because we didn't allow for
> the possibility of future additions to this part of the platform?

What future headaches? As I said before, thus far we never found a
need to expand this kind of API. See setInterval(),
addEventListener(), ... Furthermore, returning an object means keeping
a larger object in memory, it means we need to decide if it should
have a constructor and what the purpose of said constructor is going
to be.


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Glenn Maynard
In reply to this post by Anne van Kesteren-4
On Thu, Jan 10, 2013 at 6:47 AM, Anne van Kesteren <[hidden email]> wrote:
On Thu, Jan 10, 2013 at 3:35 AM, Jonas Sicking <[hidden email]> wrote:
> In order for that to work you need to do selector-based filtering of
> event.target, not event.currentTarget.

Yeah, my bad.

(Just sanity checking: you're getting my mail, right?  I mentioned this early in the thread.)


On Thu, Jan 10, 2013 at 7:41 AM, Anne van Kesteren <[hidden email]> wrote:
On Thu, Jan 10, 2013 at 2:38 PM,  <[hidden email]> wrote:
> I believe it has been mentioned that an object leaves the door open for future enhancements.  Returning only a function limits your options for future enhancements.

Given that there's ample precedence for such APIs in setInterval() and
such I'm not too worried about that. Enhancements will always be
possible one way or another. Memory usage and added complexity are
also considerations.

setInterval is a terrible legacy API that shouldn't be mimiced.  It has no isolation between code; any script can do for(i=0; i<100000;++i) clearInterval(i); and clear timers for code it has nothing to do with.  This isn't possible with event listeners: if you don't have a reference to the appropriate object--the listener function, currently--it's impossible to accidentally unregister it.

I don't know why returning a function would use less memory than returning an object, since functions *are* objects, and the function would still need to be a closure.  (I wouldn't be surprised if implementing the function version is actually more work in some browsers, since while returning an object is commonplace, creating a closure from native code may be less common.  But I'm not an implementor, so a parenthetical...)

On Fri, Jan 11, 2013 at 7:33 AM, Anne van Kesteren <[hidden email]> wrote:
What future headaches? As I said before, thus far we never found a
need to expand this kind of API. See setInterval(),
addEventListener(), ...

setInterval is orders of magnitude simpler API than DOM events, so it isn't a useful comparison.  I don't understand the reference to addEventListener (events are exactly what we're talking about expanding on right now).

I've already given an example of something else this API might do in the future, based on an actual, live API.  http://prototypejs.org/doc/latest/dom/Event/Handler/prototype/start/index.html


On Thu, Jan 10, 2013 at 9:19 AM, Robin Berjon <[hidden email]> wrote:
Actually, just because it's a function doesn't mean it can't be extended:

var obj = function () { console.log("stop"); };
obj.start = function () { console.log("start"); };
obj();
obj.start();

Whether that's elegant is another question.

This is exactly the sort of nasty contortion I mentioned earlier--something we clearly wouldn't want to have to do.

Returning an object is also clearer, since it gives the method a name; returning a function is opaque.  I don't know why we'd deviate from the standard pattern here.

-- 
Glenn Maynard

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Anne van Kesteren-4
On Fri, Jan 11, 2013 at 4:30 PM, Glenn Maynard <[hidden email]> wrote:
> (Just sanity checking: you're getting my mail, right?  I mentioned this
> early in the thread.)

Yeah. I just mentioned it because apparently Jonas had not seen that.


> On Fri, Jan 11, 2013 at 7:33 AM, Anne van Kesteren <[hidden email]> wrote:
>> What future headaches? As I said before, thus far we never found a
>> need to expand this kind of API. See setInterval(),
>> addEventListener(), ...
>
> setInterval is orders of magnitude simpler API than DOM events, so it isn't
> a useful comparison.  I don't understand the reference to addEventListener
> (events are exactly what we're talking about expanding on right now).

It is a useful comparison as it's the same kind of problem: adding and
removing a callback. It seems you trimmed down too much here, it gave
the reasons for why an object is problematic.


> I've already given an example of something else this API might do in the
> future, based on an actual, live API.
> http://prototypejs.org/doc/latest/dom/Event/Handler/prototype/start/index.html

Is it in use?


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

James Graham-7
In reply to this post by Anne van Kesteren-4
On 01/11/2013 02:33 PM, Anne van Kesteren wrote:
> Furthermore, returning an object means keeping
> a larger object in memory,

I don't think that this mind of micro-optimisation is a valid argument
here. Creating an event handler isn't something that you have to do
thousands of times in a tight loop. Indeed with the delegation pattern
that we are trying to support here you dramatically cut down the number
of listeners that are required compared to the one-listener-per-target
approach.


Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Glenn Maynard
In reply to this post by Anne van Kesteren-4
On Fri, Jan 11, 2013 at 9:38 AM, Anne van Kesteren <[hidden email]> wrote:
> On Fri, Jan 11, 2013 at 7:33 AM, Anne van Kesteren <[hidden email]> wrote:
>> What future headaches? As I said before, thus far we never found a
>> need to expand this kind of API. See setInterval(),
>> addEventListener(), ...
>
> setInterval is orders of magnitude simpler API than DOM events, so it isn't
> a useful comparison.  I don't understand the reference to addEventListener
> (events are exactly what we're talking about expanding on right now).

It is a useful comparison as it's the same kind of problem: adding and
removing a callback. It seems you trimmed down too much here, it gave
the reasons for why an object is problematic.

You're saying "we've never needed to add other behavior to the return value of setInterval, therefore we probably will never need to do so for event handlers", which is drawing a conclusion from a bad comparison, IMO.

I trimmed a reason I responded to elsewhere (which you trimmed :), and a non-reason: no, it shouldn't have a constructor since there are no use cases for one, and it can be added later if they arise.  (Deciding that isn't an argument against using an object.)

> I've already given an example of something else this API might do in the
> future, based on an actual, live API.
> http://prototypejs.org/doc/latest/dom/Event/Handler/prototype/start/index.html

Is it in use?

I don't know.  The point is there are clear downsides (being unusual on the platform and resulting in slightly less clear code), some possible downsides (the above), and the arguments for it seem questionable.  The arguments I've seen for a function are:

- Returning a closure somehow uses more memory than returning an object, and enough to matter.  This seems questionable.  Do you have data?  Both create an object that needs to be GC'd; they're just different objects.
- Returning a closure is simpler than returning an object.  Have implementors actually said they'd implement this if it was a closure, but not if it was an object, because objects are so complex?

They both feel like premature optimizations to me.

(I could see an object-based API that doesn't create an object requiring GC, essentially by returning an integer like setInterval, but boxed in an immutable container that's copied by value.  Copying by value avoids the need for it to be collected, and boxing it avoids the "clearing timers accidentally" problem I mentioned earlier.  However, this might be hard to implement if there's nothing like that in JS engines already.)

On Fri, Jan 11, 2013 at 10:40 AM, James Graham <[hidden email]> wrote:
I don't think that this mind of micro-optimisation is a valid argument here. Creating an event handler isn't something that you have to do thousands of times in a tight loop. Indeed with the delegation pattern that we are trying to support here you dramatically cut down the number of listeners that are required compared to the one-listener-per-target approach.

My recommendation is that we extend addEventListener, not add a new API.  (I don't like the idea of adding a whole new API optimized just for delegation--we should be able to avoid that.)  That means the object would be returned by addEventListener.  If returning an object from addEventListener is too much of an added cost, I'd expect returning a function to be too, though.

-- 
Glenn Maynard

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Jonas Sicking-2
In reply to this post by Anne van Kesteren-4
On Thu, Jan 10, 2013 at 4:47 AM, Anne van Kesteren <[hidden email]> wrote:
> On Thu, Jan 10, 2013 at 3:35 AM, Jonas Sicking <[hidden email]> wrote:
>> foo.addEventListener("click", object.clickhandler.bind(object));
>>
>> which is pretty verbose.
>
> We discussed this in depth before when discussing the approach for
> callbacks. We decided bind() was exactly the kind of feature that can
> be used for this and maybe future editions of JavaScript should make
> it easier to use, but that we would not try to work around it.

Fair enough.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Glenn Maynard
In reply to this post by Glenn Maynard
On Sat, Jan 5, 2013 at 1:30 PM, Glenn Maynard <[hidden email]> wrote:
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.

I think this proposal needs more consideration.  It's a simple, consistent overload of an existing API, instead of a new API.  I've been told that it's "confusing", but not how or why.  It seems simple and obvious to me, so I don't know how to address this.  It seems much simpler than having two distinct event listener APIs.  It doesn't give a nice two-letter function name, but that's not a reason to have two APIs (at most it simply means making an alias).

--
Glenn Maynard

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Anne van Kesteren-4
On Tue, Feb 12, 2013 at 12:31 AM, Glenn Maynard <[hidden email]> wrote:
> I think this proposal needs more consideration.  It's a simple, consistent
> overload of an existing API, instead of a new API.  I've been told that it's
> "confusing", but not how or why.  It seems simple and obvious to me, so I
> don't know how to address this.  It seems much simpler than having two
> distinct event listener APIs.  It doesn't give a nice two-letter function
> name, but that's not a reason to have two APIs (at most it simply means
> making an alias).

Overloading an existing API to make it work completely different
simply does not seem like a good strategy. We should just map it to
the same underlying concepts.


--
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: Better event listeners

Glenn Maynard
On Tue, Feb 12, 2013 at 7:58 AM, Anne van Kesteren <[hidden email]> wrote:
On Tue, Feb 12, 2013 at 12:31 AM, Glenn Maynard <[hidden email]> wrote:
> I think this proposal needs more consideration.  It's a simple, consistent
> overload of an existing API, instead of a new API.  I've been told that it's
> "confusing", but not how or why.  It seems simple and obvious to me, so I
> don't know how to address this.  It seems much simpler than having two
> distinct event listener APIs.  It doesn't give a nice two-letter function
> name, but that's not a reason to have two APIs (at most it simply means
> making an alias).

Overloading an existing API to make it work completely different
simply does not seem like a good strategy. We should just map it to
the same underlying concepts.

It doesn't work completely differently.  It works exactly the same.  addEventListener("click", func, true) would be exactly equivalent to addEventListener("click", func, {capture: true}).

--
Glenn Maynard

123