Everything you think you know about data binding — and every trick MVC libraries are using to pull it off — is about to be flipped on its head.
At the last ECMA/TC39 Face to Face, Rafael Weinstein presented the latest revision of the Object.observe spec, a work in progress that he and several other members of TC39 are currently authoring. Object.observe is under discussion in TC39 and will hopefully be in a future edition of the ECMAScript 262 standard. To test drive it today, grab this special build of Chromium.
Note: by default, get/set accessors won’t notify, but you can create custom notifiers, which I will show you below.
Object.observe will grant observability only for objects that are explicitly specified in a program—like this:
While that example shines with simplicity, there is more! We can also retrieve a notifier object, with
Object.getNotifier and call its
notify() method with a change record; this allows you to create your own accessor notifiers—take a look:
Changes are delivered asynchronously, at the end of every “turn”. Notice the the last value in the change set is the present value…
Notice only one “Observed…” was logged in the last example? Same turn changes are delivered together, “sometime in the future” (for explanation of how this model works, take a look at the DOM Mutation Observer spec ):
In the output, you’ll see that the “present value” is the value that we expect it to be when the
[...].forEach(...) call is complete–that’s the end of the turn.
When the program requires earlier delivery or any sort of immediate control over delivery,
Object.deliverChangeRecords(callback) will force an immediate delivery if there are pending changeRecords:
The rationale behind
Object.observe is to provide a native, highly optimized implementation on which data binding strategies can be built. Modern web applications are generally built using one of these—primarily for some degree of data-binding, along with additional goodies to simplify the workload.
Object.observe is not a drop in replacement by any means, however it does spell the end for atrocious workarounds that include property polling and DOM event “hook-binding” (latching onto every key event fired on a document is insane). In a not-too-distant future, data-binding libs will built on top of smart, asynchronous, natively optimized object observation patterns with
Object.observe at the core.
If you’re the author of a data-binding library, I’d like to take this opportunity to challenge you to re-write your code base using
Object.observe as the core of your data observation strategy. The idea is to maintain your current API, but drop whatever mechanism you’re currently using and replace it with one built on top of
Object.observe. Post links to your repo branches in the comments.
A special build of Chromium that has a prototype implementation of
Object.observe is available develop your code and run tests against.
In the meantime, I’ve put together an example data-binding API called Fact that you can use as a guide for getting started on your own re-writes. All of the feedback you provide will be used by ECMA/TC39 to guide the development of the spec.