Re: addEventListener and side-effects

On Tue, Sep 6, 2011 at 10:10 AM, Robin Berjon <robin@berjon.com> wrote:

> Right, but part of the question is whether triggering an event upon
> registration is indeed a side-effect.


It's a side-effect by definition.  The only side-effect registering an event
listener should have is the registration of an event listener.

Side-effects of adding event listeners is outside the vocabulary of the
event model.  There's no way, for example, to implement these side-effects
from JavaScript.  They also don't get along with event capture, if this is
ever applied to a non-root node--the entire tree would need to be traversed
to see what side-effects need to happen.

> This is to provide the web app with the orientation without it having to
wait until the orientation changes.

Remember that wanting this isn't unique.  You may want to know the current
position of the mouse when registering mousemove, or whether an element is
focused when registering focus, but those events aren't fired on
registration, either.


This seems like an unnecessary complication, anyway.  In the existing WebKit
implementation, this information is in window.orientation; the
orientationchange event is fired when it changes, but doesn't contain the
change itself.  You don't need to fire the event; user code simply looks
like:

function orientationchange() { alert(window.orientation); }
window.addEventListener("orientationchange", orientationchange, false);
orientationchange();

-- 
Glenn Maynard