Fluxとはなんだったのか + misc at 2014

はじめに

VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。

結局”Flux”なんだったのよ

詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebook命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、本質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイントだと思う。

Virtual DOMと組み合わせて語られることが多いけれど、別にVirtual DOMがないとFluxパターンができないわけではない。StoreからViewに向けて放たれるメッセージの粒度を、「n番目にデータを追加」「n番目から削除」「n番目を変更」などのように細かく刻んでいけばViewが何のライブラリで組まれていようが成立する。メッセージ化した時点でコマンドパターンになっていくわけだしね。

ただ、メッセージを細かく刻んでいく作業は結構だるい。そこでVirtual DOMと組み合わせると、一度に全てのデータを渡しても、どうせVirtual DOMの差分検出が面倒を見てくれるので、メッセージ粒度が「データ構造に変更あり」という粗さでも大丈夫なようになるという話。そして一回のメッセージと状態の変更を紐付けるのが容易になり、状態のスナップショットも確保しやすくなり、undo操作などの実装がシンプルなものになるというだけの話。

Fluxフレームワークについて

特にフレームワークなくても実践できるだろ

なぜ私はReact.jsを使うのか

なぜ私はReact.jsを使うのか?

  • MVCで言うところのViewとなるDOMのサブツリーの生成をテンプレートエンジン的に扱いたい
  • 適切な粒度でビューコンポーネントを分割して閉じ込めたい
  • Facebookという胴元がちゃんと自分たちで使ってることへの信頼
  • ドキュメントが非常にマトモ
  • dangerouslySetInnerHTMLとかgetDOMNode()のような緊急ハッチがある

これだけ。特に最初の2つが重要で、UIを作ろうとした場合に大きな助けとなる。

Reactの発明は成立由来からしても、UIのコンポーネント化・テンプレート化をカジュアルに行える点であり、Virtual DOMは彼らにとっては速度面のトレードオフを抑え込むためのトリックにすぎない。

別に同じVirtual DOMを使うだけであればReactよりも速いライブラリもあるのだけど、そんなものはReact.jsでパフォーマンスが問題になった時に使えばいいと思ってるし、究極的には生のDOM操作を書けば解決する問題であるし、それでも遅いならその時考えればいい話なので、全く気にしていない。