all articles

フロントエンドでデーターバインディングについての話し

2016-01-08 @sunderls

JS

最近面白い記事を見ました http://teropa.info/blog/2015/03/02/change-and-its-detection-in-javascript-frameworks.html#cmid=23653

抜粋します。

(以下のイメージは元記事からホットリンクしています、すいません)

昔では、レンダリングはサーバーサイドでやってた

なにをタップしたら、ページ遷移しちゃって、domが一新されます。 これはjsがない時代ですね。

model dataが何か変化あったら、domが全部切り替えられて、変化の部分はもちろん反映されます。

手動でre-rendering

Backbone, Ext.jsとかで、modelの概念が出て、modelが変化したら、なにをするのは自分で決めます。

viewの背景にmodalがある、model変化する時change eventがあります。

テンプレートは関わらず、jsとしては、bindingについてはわからない、ただテンプレートをレンダリングします。

data binding

それから、bindingがきました。framework(Ember.js)として、viewとmodalの関係は明確に記述されるので、

dataが変化したら、自動的にviewを更新してくれます。

でも、dataが変わったっていうのは、famework自体が探知できなく、手動で教えないといけないです。

例として、foo.x=42ではダメで、foo.set('x',42)でいけます。

angular.js dirty checking

そのset/getの手間は省けるのかなと、angular.jsはdirty checkingをやってて省けています。

テンプレート中のエクスプレションンは全部watchersとして、angular.jsが記録してます。

ユーザーアクション、api request, timeoutなどaction があれば、angular.jsはwatchersを実行し、 変わったものをピックアップして、応じるdomを変えます。

react.js Virtual dom

React.jsは一個の疑似dom treeを作って、さらにhtml domを生成する。

変化があったら、再度疑似dom treeを作って、今の疑似dom treeと比べる。 diffした結果だけは、html domに反映するのは基本です。

便利でしかも早いです。

Om: immutable data structures

上記の図から見ると、diff アルゴリズムはleafまで探索しないと変化がないことは確認できないです。 immutable data structuresを導入すると、変化ある部分だけdiffできるようになって、無駄なチェックは省けます。

まだまだこれからもっと素晴らしいものでますかね。