RE: Better event listeners

What about just... "off"?

> -----Original Message-----
> From: Brandon Wallace [mailto:brandon.wallace@yahoo.com]
> Sent: Tuesday, January 8, 2013 21:20
> To: Jake Verbaten; Glenn Maynard
> Cc: Anne van Kesteren; www-dom@w3.org
> 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 <raynos2@gmail.com>
> To: Glenn Maynard <glenn@zewt.org>
> Cc: Anne van Kesteren <annevk@annevk.nl>; "www-dom@w3.org" <www-
> dom@w3.org>
> 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 <glenn@zewt.org> wrote:
> 
> On Tue, Jan 8, 2013 at 5:23 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >
> >On Mon, Jan 7, 2013 at 6:18 PM, Jake Verbaten <raynos2@gmail.com>
> 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
> >
> >
>

Received on Wednesday, 9 January 2013 02:28:24 UTC