Updates to Object.observe

Erik Arvidsson erik.arvidsson at gmail.com
Wed Jul 18 15:20:53 PDT 2012


On Tue, Jul 17, 2012 at 8:25 PM, Russell Leggett
<russell.leggett at gmail.com> wrote:
> One of the absolutely most useful things I would not want to live without in
> a databinding framework is bind to properties or property paths. It is
> extremely common to want a handler to only listen for changes to a single
> property - the same way event handlers do. Something like:
>
>     Object.observe(o,"x",observer);
>
> Which would only be notified of changes to x, instead of having to check
> which property each time. Its a minor thing, but common.
>
> In my framework it is also possible to databind to a whole path - so lets
> say something like:
>
>     Object.observe(o,"x.y", observer);
>
> This would be "attached" at o, but it listens down the whole path, so a
> change to the y on x would fire, but a change to x would fire also fire with
> the new x's y property. This would automatically remove any observers from
> the old x.y path and attach observers to the next x.y path. This sort of
> thing is incredibly common and powerful in data bound templates.

I agree that this is a very common feature. For this iteration, we
wanted to provide the minimal building blocks to allow these kind of
things to be built.

> A way of firing the callback immediately on attaching - as a way of sort of
> priming any state that depends on the binding. If I have o1 and o2 and I
> want them to stay in sync one way - if I attach an observer to o1, I might
> want it to immediately fire with all of the current values of o1 so that o2
> is up to date. I find there are many cases where one is better than the
> other so this is nice to be configurable.
> A way of making a block of changes atomically, so that multiple changes to
> the same object can be performed without firing callbacks, and then firing
> the callbacks at the end. This can be important for ensuring a consistent
> state before any observer callbacks fire. Alternatively to creating some
> kind of block, it would be powerful to have the option of tying the
> callbacks to the event loop - I believe this is what ember.js does, though
> I'm sure it could be done a lot more efficiently natively.

This is something that the proposal intentionally is not covering. The
idea is that [[DeliverAllChangeRecords]] would be called be the
embedder at the end of microtask which. Rafael spent a lot of time
getting the timing of DOM mutation observer callbacks right so I'm
sure he can provide more details.

http://www.whatwg.org/specs/web-apps/current-work/#perform-a-microtask-checkpoint

-- 
erik


More information about the es-discuss mailing list