【转】Native JavaScript Data-Binding

原文转自:http://www.sellarafaeli.com/blog/native_javascript_data_binding

Two-way data-binding is such an important feature - align your JS models with your HTML view at all times, to reduce boilerplate coding and enhance UX. We will observe two ways of doing this using native JavaScript, with no frameworks - one with revolutionary technology (Object.observe), and one with an original concept (overriding get/set). Spoiler alert - the second one is better. See TL;DR at bottom.

1: Object.observe && DOM.onChange

Object.observe() is the new kid on the block. This native JS ability - well, actually it’s a future ability since it’s only proposed for ES7, but it’s already[!] available in the current stable Chrome - allows for reactive updates to changes to a JS object. Or in simple English - a callback run whenever an object(‘s properties) change(s).

An idiomatic usage could be:

log = console.log
user = {}
Object.observe(user, function(changes){
    changes.forEach(function(change) {
        user.fullName = user.firstName + " " + user.lastName;
    });
});

user.firstName = ‘Bill‘;
user.lastName = ‘Clinton‘;
user.fullName // ‘Bill Clinton‘

This is already pretty cool and allows reactive programming within JS - keeping everything up-to-date by push.

But let’s take it to the next level:

//<input id="foo">
user = {};
div = $("#foo");
Object.observe(user, function(changes){
    changes.forEach(function(change) {
        var fullName = (user.firstName || "") + " " + (user.lastName || "");
        div.text(fullName);
    });
});

user.firstName = ‘Bill‘;
user.lastName = ‘Clinton‘;

div.text() //Bill Clinton

JSFiddle

Cool! We just got model-to-view databinding! Let’s DRY ourselves with a helper function.

//<input id="foo">
function bindObjPropToDomElem(obj, property, domElem) {
  Object.observe(obj, function(changes){
    changes.forEach(function(change) {
      $(domElem).text(obj[property]);
    });
  });
}

user = {};
bindObjPropToDomElem(user,‘name‘,$("#foo"));
user.name = ‘William‘
$("#foo").text() //‘William‘

JSFiddle

Sweet!

Now for the other way around - binding a DOM elem to a JS value. A pretty good solution could be a simple use of jQuery’s .change (http://api.jquery.com/change/):

//<input id="foo">
$("#foo").val("");
function bindDomElemToObjProp(domElem, obj, propertyName) {
  $(domElem).change(function() {
    obj[propertyName] = $(domElem).val();
    alert("user.name is now "+user.name);
  });
}

user = {}
bindDomElemToObjProp($("#foo"), user, ‘name‘);
//enter ‘obama‘ into input
user.name //Obama.

JSFiddle

That was pretty awesome. To wrap up, in practice you could combine the two into a single function to create a two-way data-binding:

function bindObjPropToDomElem(obj, property, domElem) {
  Object.observe(obj, function(changes){
    changes.forEach(function(change) {
      $(domElem).text(obj[property]);
    });
  });
}

function bindDomElemToObjProp(obj, propertyName, domElem) {
  $(domElem).change(function() {
    obj[propertyName] = $(domElem).val();
    console.log("obj is", obj);
  });
}

function bindModelView(obj, property, domElem) {
  bindObjPropToDomElem(obj, property, domElem)
  bindDomElemToObjProp(obj, propertyName, domElem)
}

Take note to use the correct DOM manipulation in case of a two-way binding, since different DOM elements (input, div, textarea, select) answer to different semantics (text, val). Also take note that two-way data-binding is not always necessary – “output” elements rarely need view-to-model binding and “input” elements rarely need model-to-view binding. But wait – there’s more:

2: Go deeper: Changing ‘get’ and ‘set’

We can do even better than the above. Some issues with our above implementation is that using .change breaks on modifications that don’t trigger jQuery’s “change” event - for example, DOM changes via the code, e.g. on the above code the following wouldn’t work:

$("#foo").val(‘Putin‘)
user.name //still Obama. Oops.

We will discuss a more radical way - to override the definition of getters and setters. This feels less ‘safe’ since we are not merely observing, we will be overriding the most basic of language functionality, get/setting a variable. However, this bit of metaprogramming will allow us great powers, as we will quickly see.

So, what if we could override getting and setting values of objects? After all, that’s exactly what data-binding is. Turns out that using Object.defineProperty() we can in fact do exactly that.

We used to have the old, non-standard, deprecated way but now we have the new cool (and most importantly, standard) way, using Object.defineProperty, as so:

user = {}
nameValue = ‘Joe‘;
Object.defineProperty(user, ‘name‘, {
  get: function() { return nameValue },
  set: function(newValue) { nameValue = newValue; },
  configurable: true //to enable redefining the property later
});

user.name //Joe
user.name = ‘Bob‘
user.name //Bob
nameValue //Bob

OK, so now user.name is an alias for nameValue. But we can do more than just redirect the variable to be used - we can use it to create an alignment between the model and the view. Observe:

//<input id="foo">
Object.defineProperty(user, ‘name‘, {
  get: function() { return document.getElementById("foo").value },
  set: function(newValue) { document.getElementById("foo").value = newValue; },
  configurable: true //to enable redefining the property later
});

user.name is now binded to the input #foo. This is a very concise expression of ‘binding’ at a native level - by defining (or extending) the native get/set. Since the implementation is so concise, one can easily extend/modify this code for custom situation - binding only get/set or extending either one of them, for example to enable binding of other data types.

As usual we make sure to DRY ourselves with something like:

function bindModelInput(obj, property, domElem) {
  Object.defineProperty(obj, property, {
    get: function() { return domElem.value; },
    set: function(newValue) { domElem.value = newValue; },
    configurable: true
  });
}

usage:

user = {};
inputElem = document.getElementById("foo");
bindModelInput(user,‘name‘,inputElem);

user.name = "Joe";
alert("input value is now "+inputElem.value) //input is now ‘Joe‘;

inputElem.value = ‘Bob‘;
alert("user.name is now "+user.name) //model is now ‘Bob‘;

JSFiddle

Note the above still uses ‘domElem.value’ and so will still work only on <input> elements. (This can be extended and abstracted away within the bindModelInput, to identify the appropriate DOM type and use the correct method to set its ‘value’).

Discussion:

  • DefineProperty is available in pretty much every browser.
  • It is worth mentioning that in the above implementation, the view is now the ‘single point of truth’ (at least, to a certain perspective). This is generally unremarkable (since the point of two-way data-binding means equivalency. However on a principle level this may make some uncomfortable, and in some cases may have actual effect - for example in case of a removal of the DOM element, would our model would essentially be rendered useless? The answer is no, it would not. Our bindModelInput creates a closure over domElem, keeping it in memory - and perserving the behavior a la binding with the model - even if the DOM element is removed. Thus the model lives on, even if the view is removed. Naturally the reverse is also true - if the model is removed, the view still functions just fine. Understanding these internals could prove important in extreme cases of refreshing both the data and the view.

Using such a bare-hands approach presents many benefits over using a framework such as Knockout or Angular for data-binding, such as:

  • Understanding: Once the source code of the data-binding is in your own hands, you can better understand it and modify it to your own use-cases.
  • Performance: Don’t bind everything and the kitchen sink, only what you need, thus avoiding performance hits at large numbers of observables.
  • Avoiding lock-in: Being able to perform data-binding yourself is of course immensely powerful, if you’re not in a framework that supports that.

One weakness is that since this is not a ‘true’ binding (there is no ‘dirty checking’ going on), some cases will fail - updating the view will not ‘trigger’ anything in the model, so for example trying to ‘sync’ two dom elements via the view will fail. That is, binding two elements to the same model will only refresh both elements correctly when the model is ‘touched’. This can be amended by adding a custom ‘toucher’:

//<input id=‘input1‘>
//<input id=‘input2‘>
input1 = document.getElementById(‘input1‘)
input2 = document.getElementById(‘input2‘)
user = {}
Object.defineProperty(user, ‘name‘, {
  get: function() { return input1.value; },
  set: function(newValue) { input1.value = newValue; input2.value = newValue; },
  configurable: true
});
input1.onchange = function() { user.name = user.name } //sync both inputs.

TL;DR:

Create a two way data-binding between model and view with native JavaScript as such:

function bindModelInput(obj, property, domElem) {
  Object.defineProperty(obj, property, {
    get: function() { return domElem.value; },
    set: function(newValue) { domElem.value = newValue; },
    configurable: true
  });
}

//<input id="foo">
user = {}
bindModelInput(user,‘name‘,document.getElementById(‘foo‘)); //hey presto, we now have two-way data binding.

Thanks for reading. Comments at discussion on reddit or at [email protected]

时间: 2024-10-09 23:01:19

【转】Native JavaScript Data-Binding的相关文章

Native JavaScript Development after Internet Explorer

This article has nothing to do with the decision whether or not to abandon support for oldIE. You and you alone must take that decision based on the specific details of your website or application. With all this being said, let us proceed! 1. JavaScr

Data Binding Library(数据绑定库)

引子 上图中有一些 TextView 和 Button 等,正常情况下,互联网APP都会从服务器抓取数值,然后在 Activity中 findViewById 再进行setText等等.这篇文章就是用来解放你的双手劳动力 的,使用数据绑定库可以不用去findView不用在写繁琐的 setText,只要从服务器获取json 转换成 javaBean格式然后 set,duang,,,,, 所有的值就自己展现在该有的地方了. Demo: https://github.com/Afra55/DataBi

WPF QuickStart系列之数据绑定(Data Binding)

这篇博客将展示WPF DataBinding的内容. 首先看一下WPF Data Binding的概览, Binding Source可以是任意的CLR对象,或者XML文件等,Binding Target需要有依赖属性.这样便可以进行Data Binding.请看下面的示例, C# public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); DataContext = new Pe

告别findViewById(),ButterKnife,使用Google Data Binding Library(1)

Data Binding Library 用数据绑定编写声名性布局,可以最大限度的减少findViewById(),setOnClickListener()之类的代码.并且比起findViewById(),所有view是一次性初始化完成,性能更快. Data Binding Library具有灵活性和不错的兼容性,支持2.1以后的版本. 需要 Android Plugin for Gradle 1.5.0-alpha1或以上版本. 至于怎么升级? https://developer.androi

Spring Framework 官方文档学习(四)之Validation、Data Binding、Type Conversion

前言 在Spring Framework官方文档中,这三者是放到一起讲的,但没有解释为什么放到一起.大概是默认了读者都是有相关经验的人,但事实并非如此,例如我.好在闷着头看了一遍,又查资料又敲代码,总算明白了. 其实说穿了一文不值,我们用一个例子来解释: 假定,现有一个app,功能是接收你输入的生日,然后显示你的年龄.看起来app只要用当前日期减去你输入的日期就是年龄,应该很简单对吧?可惜事实不是这样的. 这里面有三个问题: 问题一:我们输入的永远是字符串,字符串需要转成日期格式才能被我们的ap

Android Data Binding 技术

Android Data Binding 技术

Android Data Binding Library 官方文档(译)

地址:https://developer.android.google.cn/topic/libraries/data-binding/index.html 本文地址:http://blog.csdn.net/jjwwmlp456/article/details/54915981 Data Binding Library (数据绑定库),旨在减少绑定应用程序逻辑和布局所需的一些耦合性代码 最低支持Android 2.1 (API Level 7) 构建环境 使用gradle插件1.5-alpha

WPF data binding

Binding这个类包含以下几个常用的属性: ElementName: Gets or sets the name of the elements to use as the binding source object. [Default is null] Source: Gets or sets the object to use as the binding source. RelativeSource: Gets or sets the binding source by specifyi

WP8.1 Study5:Data binding数据绑定

一.数据绑定 最简单的编程UI控件的方法是写自己的数据来获取和设置控件的属性,e.g. , textBox1.Text = "Hello, world"; 但在复杂的应用程序,这样的代码很快就会变得笨拙,容易出错 因此,为了更加方便,使用XAML数据绑定到你的UI链接到一个在应用程序中包含应用程序的数据的类. 这个类class:是一个对于被称为视图模型的数据绑定(ViewModel)的数据源. UI控件可以从视图模型Viewmodel类的属性自动获取其显示值,而且通过改变Viewmod