Re: Better event listeners

On 03/14/2013 11:48 AM, David Bruant wrote:
> Le 13/03/2013 16:47, Jonas Sicking a écrit :
>> One tricky issue is the exact timing of the call to the .then
>> function. It would be great if we could enable the resolver function
>> to do things like call .preventDefault on the event, but that might
>> require that the .then function is called synchronously which goes
>> against [1].
> I consider that the DOM event model is absurdly broken. Namely, all listeners being called synchronously on .dispatchEvent is a bad idea.
> I don't think retrofitting Futures into that model is a good idea. Maybe a better idea would be to add a way for event handlers to be .dispatched
> asynchronously. That would fit in the Future model, but even then I'm not sure it's a good idea.
I don't think there are too many use cases for async listeners and using setTimeout() is easy.

>
> I see Futures as a convenience (or "design pattern" maybe) written on top of events (the general idea of events, not necessarily the ones defined in
> the DOM). An object having mutually exclusive success/error events where at most one will be fired is pretty common and Futures makes an idiom out of
> this recurring pattern.
> But not all events follow this pattern. "readystatechange" is meant to be fired several times, for instance.
>


> If people want to make a future out of an upcoming existing event, they can do so in a few lines (as expressed here [1]). Maybe it will be a very
> common pattern for futures, but it's not certain.
agree

> Maybe people will use that only for a handful of other events and we'll see a different pattern emerge.
> I'd be more in favor of shipping minimalistic futures, see how people use them and add hooks to DOM events after having a better understanding of how
> people use events in combination with Futures, but not before.
and agree even more.



-Olli

Received on Thursday, 14 March 2013 10:18:14 UTC