Re: Better event listeners

+1 :D


On Tue, Jan 8, 2013 at 9:27 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

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