Re: Mutation events replacement

On Wed, Jun 29, 2011 at 6:11 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>  > Maybe this is a stupid question, since I'm not familiar at all with
> > the use-cases involved, but why can't we delay firing the
> > notifications until the event loop spins?  If we're already delaying
> > them such that there are no guarantees about what the DOM will look
> > like by the time they fire, it seems like delaying them further
> > shouldn't hurt the use-cases too much more.  And then we don't have to
> > put further effort into saying exactly when they fire for each method.
> >  But this is pretty obvious, so I assume there's some good reason not
> > to do it.
>
> To enable things like widget libraries which want to keep state
> up-to-date with a DOM.
>

I agree that in many cases, libraries will be able to update states before
application gets back control.  However, callbacks are called synchronously
sometimes and asynchronously sometimes might cause problems in some
situations.  Consider the following situation.

I write a function that mutates DOM and updates some internal state based on
a value automatically provided by some library (say jQuery, etc...) upon in
a DOM mutation callback.

Later, my colleague adds new feature and decides to call my function in a
middle of DOM mutation callback.  And oops!  My function doesn't work
because it relied on the assumption that DOM mutation callbacks are called
synchronously when I mutate DOM.

- Ryosuke