Re: [dom-futures] Making ProgressFuture use real events

On Wed, Apr 3, 2013 at 11:45 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Apr 3, 2013 at 10:43 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> The ProgressFuture strawman at
>> <https://github.com/slightlyoff/DOMFuture/blob/master/ProgressFuture.idl>
>> augments a future with an analog of progress events.
>>
>> Why isn't this just using actual events?  That is, make ProgressFuture
>> an eventTarget as well, which fires progress events.
>>
>> I'm fine with the existing API existing as it is, where convenience
>> APIs are provided both for firing (a 'progress' method on the
>> resolver) and listening to (a 'progress' method on the future)
>> progress events.  It just seems weird to implement events without them
>> being actual Events.
>
> Define "seems weird".
>
> Using Events as a way to do callbacks has many advantages when using
> them on Nodes. However they provide much less value when used on
> "standalone objects" like XMLHttpRequest and a Future object. With
> using a callback it means that we can both provide a more convenient
> registration syntax:
>
> doSomeAsyncThing(...).progress(showProgress).then(processResult, handleError);
>
> Additionally the actual progress handler gets a cleaner API. Instead
> of having an Event object that has a bunch of irrelevant stuff on it,
> like .stopPropagation(), .preventDefault() and .bubbling, the caller
> just gets the relevant data.
>
> We've come to use Events as a general callback mechanism. However
> that's never been where they shine. Using Events here just causes more
> edge cases to define for us, likely more code for implementations, and
> more and less convenient API for authors.

I'm fine if this kind of break is *intentional*.  It wasn't clear to
me that it was - it just looked like the API was reinventing events in
a custom way, just like so many APIs reinvent futures in a custom way
right now.

If that's the case, it should be documented somewhere that, if you're
attaching something event-like (where 0+ listeners subscribe to 0+
notifications) to a future, but don't need the full DOM event system,
you should do it in this particular way.

~TJ

Received on Wednesday, 3 April 2013 19:41:27 UTC