Re: Better event listeners

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.

--
Brandon

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