cycle.js やってる

javascript がブラウザ上ではしりだしたとき、自分のコードは画面になにが表示されているのか何も知らなくて、document.getElement* だとか querySelector や $ とかをしてまず検索してとってきてはじめてわかる。javascriptで画面をいじるときはまず検索。これは、画面内のすべてをjavascriptでハンドリングしたいとき 、とても奇妙に感じる。ネイティブアプリケーションならば、実行時に即、Viewのオブジェクトの参照にさわれる状態でスタートするわけだから、そうなってないのが若干おかしいという感覚。

DOMオブジェクトと自分のコードの距離はおもっているよりも離れていて、jqueryからangular的なものからreact的なものまで、その距離を埋めることに注目していたような気がする。Viewを完全に自分の支配下の置き言うことを聞かせる。angular前後でその目的は達成され、Viewは完全に言うことを聞くようになったのかもしれないけど、今度はコード全体のAPIがViewを中心にまわっていて、UIイベントは綺麗に書けるけどそれ以外を分離するためにコードベースがでかめだったりしていた。React も、Viewに値をどう結びつけるのか考える過程でアーキテクチャがでかめになっているようだ。

なぜ View とビジネスロジックを分離していくとフレームワークがでかくなるのか。考えてみると不思議だ。フロントエンドのプログラミングといえば非同期処理で、それはUI Eventだけじゃないはず。ウェブあぷりけーしょんなら必ず通信はついてまわるし、今後他の要素も増えてくると考えると、はじめからViewは入出力の重要な要素ではあれどその一部でしかないとも言える。

cycle.js はViewふくめた全ての入出力を統一的に扱う。ただし、図にあるとおり、アプリケーション全体で Observable をまとめていく必要があるので、統一的な方法で分離していくのがむずかしい感じはある。

どちらかというと cycle.js より やっぱ RxJS がめちゃめちゃ良い。 Rx と Matt-Esch/virtual-dom 的なものの組み合わせるもっと良い方法おもいついたらいいな。。