W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

Re: Better event listeners

From: <brandon.wallace@yahoo.com>
Date: Sat, 16 Mar 2013 09:20:22 -0500
Message-Id: <352DDD7F-7FCA-42DB-81F1-825AA30BC684@yahoo.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Rick Waldron <waldron.rick@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, "www-dom@w3.org" <www-dom@w3.org>, Yehuda Katz <wycats@gmail.com>
To: David Bruant <bruant.d@gmail.com>
As an author, I very rarely need to subscribe to a single occurrence of an event.  The vastly more common case is to subscribe to a stream of events until some condition is met, then unsubscribe from the stream.

Since a future represents a single occurrence of an event, it can really only be used in the rare case, but not in the common multi-occurrence case.  But then I would have to choose to use a different API (Futures) for this rare case.  Why would I do that, when I could instead use the common streaming API and just unsubscribe when the event occurs?

RxJs has bindings to map events to observables, which is a much more natural fit since Rx observables represent a stream of events.  I use this mapping all the time.  In the rare case that I only want a single occurrence of the event, I just append  ".take(1)" to the end of the observable.

This is why I, at least, am not interested in the ability to map events to futures.


On Mar 16, 2013, at 8:49 AM, David Bruant <bruant.d@gmail.com> wrote:

> [cc'ing Rick Waldron. For context start of the relevant part of the thread at http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0202.html ]
> Le 14/03/2013 10:48, David Bruant a écrit :
>> Le 13/03/2013 16:47, Jonas Sicking a écrit :
>>> One tricky issue is the exact timing of the call to the .then
>>> function. It would be great if we could enable the resolver function
>>> to do things like call .preventDefault on the event, but that might
>>> require that the .then function is called synchronously which goes
>>> against [1].
>> Maybe people will use that only for a handful of other events and we'll see a different pattern emerge.
>> I'd be more in favor of shipping minimalistic futures, see how people use them and add hooks to DOM events after having a better understanding of how people use events in combination with Futures, but not before.
> I've spent some time looking at jQuery and since they've added Deferred [1] (a promise-family mechanism), I haven't found evidence that they turn an event to a deferred.
> I'll let jQuery experts Yehuda and Rick tell me if I'm wrong.
> I also haven't found sign of other libraries doing that either (people knowing about other libraries can jump in here)
> Assuming I am not mistaken on how jQuery Deferred and events don't interact, I take that as a signal that it might not be something people use and probably even need.
> David
> [1] http://api.jquery.com/jQuery.Deferred/
Received on Saturday, 16 March 2013 14:20:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:43 UTC