Re: Better event listeners

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

David

[1] https://github.com/slightlyoff/DOMFuture/issues/34#issuecomment-14236676

Received on Thursday, 14 March 2013 09:48:43 UTC