[whatwg] Storage Events for a Specific Storage Area

Joseph Pecoraro joepeck02 at gmail.com
Wed Jun 24 21:34:44 PDT 2009


>> This doesn't break anything in the current spec.  So it wouldn't  
>> break
>> any existing implementations.  I'm also guessing that the groundwork
>> for implementing a feature like this is already in place due to the
>> ubiquity of addEventListener.
>
> To be frank, it seems like a lot of bloat though to avoid a simple  
> comparison.

Its my thinking that the simple comparison shouldn't be necessary to  
begin with.  Thats why I suggested this.

This is a probably a bad analogy, but would it make sense to put a  
"click" function on just the window object and check every time it  
fires to see if it fired in the <div> you were interested in?  Imagine  
every single "click" listener you register fires every time you click  
on something... that doesn't scale.  (The reason this is a bad is  
because these "click" events "bubble".  Maybe bubbling is appropriate  
here)?


>> - Less Listener Functions Fired - Instead of every registered  
>> listener
>> getting fired on every "storage" event, only those applicable will be
>> fired.  This may mean overall less listeners getting fired, and code
>> that doesn't have to continually check the affected storageArea,
>> leading to potential performance improvements.
>
> Actually, assuming only one of the two solutions would exist the  
> same amount of events would fire. A change to localStorage causes an  
> event to be dispatched and likewise a change to sessionStorage  
> causes an event to be dispatched. Having said that, with your  
> solutions more events will fire since the legacy event will have to  
> be dispatched too.

What do you mean when you say "more events will fire?"  Why not just  
fire the same "storage" event but now put the if statement that the  
web developer had to "always write" and put it into the browser's  
dispatching code.  This may be my inexperience with the  
implementations, but I honestly don't see how this could end up firing  
more events.

I think looking at it this way ("more events") is looking at it  
sideways and maybe a bit pessimistically.  If my first thought is  
"this is going to be really complex" then my next thought is "how can  
I simplify this" and if I can't find a way to simplify it I would  
state why it can't or shouldn't be done.  I don't see that here, I  
just see the "this is really complex" part.  I'm guessing that there  
is a simpler way to look at this, and if not I'd be interested to know  
why this seems so complex.


- Joe



More information about the whatwg mailing list