W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2015

Re: [sensors] Dependency on [DOM] due to inheriting from EventTarget

From: zenparsing via GitHub <sysbot+gh@w3.org>
Date: Fri, 12 Jun 2015 03:46:26 +0000
To: public-device-apis@w3.org
Message-ID: <issue_comment.created-111343884-1434080785-sysbot+gh@w3.org>
> honestly, I'd rather see Sensor wait for EventEmitter than continue 
down the path with EventTarget and all of the baggage it entails.

I find this a little odd since, from my point of view, EventEmitter 
and EventTarget are equally terrible user-facing APIs, in that neither
 one allow for composition and abstraction.

For instance, if you are modeling a push stream and using Observable, 
then "once" doesn't need to be implemented at the API level;  it can 
instead be implemented as a standard combinator over all observables:

(Taking some liberty with the proposed `::` operator.)

```js
function first() {
    return new Observable(sink => {
        let subscription = this.subscribe({
            next(v) { 
                sink.next(v);
                // Stop listening after we've received one event
                subscription.unsubscribe();
            },
            throw(v) { sink.throw(v) },
            return() { sink.return() },
        });
    });     
}

sensor.observe("change")::first().forEach(x => {
    // do whatever, but only once
});
```

I'm not saying the Sensor API should necessarily be implemented using 
observables, but I think we should be looking forward to compositional
 solutions like Observables and AsyncIterators rather than old-school 
event dispatch APIs like EventTarget and EventEmitter.

-- 
GitHub Notif of comment by zenparsing
See https://github.com/w3c/sensors/issues/21#issuecomment-111343884
Received on Friday, 12 June 2015 03:46:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC