Updates to Object.observe

Rafael Weinstein rafaelw at chromium.org
Wed Jul 18 20:35:53 PDT 2012

On Wed, Jul 18, 2012 at 3:20 PM, Erik Arvidsson
<erik.arvidsson at gmail.com> wrote:
> 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

Callbacks will never fire synchronously. All changes within a given
"unit" are done atomically and observers are notified after this. In
the browser context, a "unit" will most often be a single event
handler. When the event handler exits, observers will be delivered
change records.

>> 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