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

Re: Better event listeners

From: Brandon Wallace <brandon.wallace@yahoo.com>
Date: Tue, 8 Jan 2013 18:19:51 -0800 (PST)
Message-ID: <1357697991.95405.YahooMailNeo@web162205.mail.bf1.yahoo.com>
To: Jake Verbaten <raynos2@gmail.com>, Glenn Maynard <glenn@zewt.org>
Cc: Anne van Kesteren <annevk@annevk.nl>, "www-dom@w3.org" <www-dom@w3.org>
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:20:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 January 2013 02:20:21 GMT