Hi Steve,
Thanks for joining the conversation. =-)
The automatic dependency discovery that Knockout does is rather cool.
My sense has been that Proxy is a better tool for this job than is
expanding the semantics of Object.observe() to include reads.
Object.observe() only operates on objects which are specifically
observed, so something like
get val function() {
this.foo.bar + this.bat.baz;
}
Would only report access to this.foo and this.bat, but not foo.bar and bat.baz.
While applying the function to a proxy wrapper allows for the creation
of a "membrane" through which you can discover dependencies not
available on the local object.
Is my thinking flawed?
Note that the Object.observe() specifically reports when properties
are reconfigured such that any approach you take to computed
properties can know when it needs to invoke its strategy and when it
can rely on the system-generated change records.
On Wed, Aug 22, 2012 at 3:34 AM, Steve Sanderson <fla...@gmail.com> wrote:
> This is fantastic - thanks for pushing this forwards, Rafael!
>
> For context, I'm part of the knockout.js (a JavaScript MV* library) team, so
> I have some interest in how this could work out. This spec has a lot of
> potential to make MVC-style coding far simpler and more robust, both for
> framework developers and web app developers. Although the semantics of the
> Object.observe proposal are different in a few ways from what Knockout and
> similar frameworks use for observability, it certainly looks applicable
> enough to the same design patterns and APIs.
>
> There's one significant extra aspect of observability that Knockout, Batman,
> CanJS, and other MVC-type frameworks rely on that isn't covered as far as I
> can tell by the proposal so far. These frameworks can automatically
> determine the dependencies of an arbitrary block of code. For example, if
> there is a block of code that determines the output of a computed property,
> like this:
>
> function fullName() { return firstName + " " + lastName };
>
> ... then if you use such a function during a declarative binding, those
> frameworks' observability mechanisms will automatically know which
> underlying observable properties it depends on. This is possible because the
> frameworks' observabilty mechanisms can notify on read as well as on write.
> This ends up being a very powerful and flexible feature whereby the
> framework can manage arbitrary and dynamically-changing dependency chains,
> and the developer can robustly call arbitrary custom functions in computed
> property evaluators and bindings.
>
> These facilities could be made possible in the Object.observe proposal by
> adding one further primitive feature. Just as you can register for
> notifications on *write*, you'd ideally also be able to register for
> separate notifications on *read*. Typically only framework code would do
> that - application code wouldn't usually need to. The actual dependency
> detection logic would differ depending on whether read notifications were
> delivered synchronously or asynchronously, but then everything else can be
> built on top of that primitive.
>
> Please let me know if you want more detailed descriptions of how any of this
> works in Knockout/etc. I'd be happy to suggest how a comparable API might
> look in the Object.observe world!
>
> Regards
> Steve
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
