[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