Updates to Object.observe
russell.leggett at gmail.com
Tue Jul 17 20:25:01 PDT 2012
On Tue, Jul 17, 2012 at 9:54 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
> On Tue, Jul 17, 2012 at 7:49 PM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:
>> We've done a bunch of updates to Object.observe in preparation for the
>> next weeks face to face meeting. The updates are based on feedback
>> from multiple people but more feedback is always welcome.
> This is really shaping up nicely!
> I have a only a few small pieces of feedback at the moment and I apologize
> in advance, because the first is definitely bikeshedding.
> The term "unobserve" feels clumsy, mostly because it's not a word, whereas
> "unobserved" is a word — but is an adjective, not a verb. Prefixing words
> with "un" is done so to reverse them, eg. I zip my sweatshirt, then unzip
> my sweatshirt. As a programmer, what I really want to do is "ignore" any
> further changes, right? "ignore" is actually the opposite of observe, so it
> makes sense that I would...
Another possibility would be "addObserver" and "removeObserver" to match
addEventListener and removeEventListener - although I shudder to model any
method names from the DOM.
I like how simple and clean this is. Having implemented a databinding
framework myself, I certainly appreciate the benefit this would provide.
However, this is really only a building block and not a full solution.
There will still likely have to be libraries that build on top of this for
most cases. That might be fine, but I have a few possible suggestions in
case there is some room to expand the API a little.
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:
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:
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 would understand if this expanded the API, but if there's an effort here
to provide common features, that would be up at the top for me.
Another couple of other things to consider:
- 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss