On Wednesday, August 22, 2012 at 6:34 AM, Steve Sanderson 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.
Couldn't this be accomplished via get accessor and firing a notification from
within the accessor function when properties are read?
> 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
