なぜReactなのか

React, Cyclejs, Reduxを学んだ上でこれらの技術が何を解決したのかまとめてみる。発想はオリジナルではなく、今まで私が読んだ記事から拝借した解釈などが含まれている。たぶんReact, Fluxを学んだ人にとっては当たり前の感覚を言語化しているだけの内容となる。

TL;DR

Q: なぜReactなのか
A: フロントエンドが自由度の高いGUIアプリケーションになった。既存の手法では自由度の高いGUI実装を人間にわかりやすく管理することが難しくなった。

自由度の高いGUIな世界

自由度(複雑さ)の低い時代ではrender済みのDOMの上にDOMを操作する(jQueryによる)UIを載せる設計でも十分だった
現代のwebフロントエンドではVisual StudioやXcodeで作るネイティブGUIと同等の複雑さを求められる時代になっている
jQueryだけで複雑なGUIを実装するとDOMそのものが状態(State)であることが問題になる
- DOMというグローバル変数に対してあちこちからCRUDする状況で、複雑さが増すにつれて人間にはメンテできないコードになる
  - クソコードと呼ばれる状況
React ComponentはDOMと状態を切り離した上でUI部品のコンポーネント化も行った点で優れていた
- コンポーネント化は真新しい概念ではなく、おなじみの「関心の分離」
  - 人間にとって管理しやすくなることが重要
  - 再利用性が上る(こともある)、単体テストしやすくなるといった恩恵
  - コンポーネント化を担うのはReactである必要はない
- 状態の管理は有史以来プログラマを苦しめ続けたやつ
  - たとえばサーバサイドだとDBとモデルに押し込めたり、マルチスレッドだとロックをきちんととったり
  - React Componentには this.state, this.props の変更を検知してDOMをrenderするライフサイクルがある
    - React Component単体ですでにDOMの状態を変更するフローは一方向になっている
    - DOMの状態を変化させるフローをUI設計全体に適用したのがFlux
  - FluxもReact Component同様に状態の変化に制約を与えるのが目的
    - 複雑な問題は制約を与えることで解きやすくなるし人間にとって認知しやすくなる
    - UI実装がスケールするならFlux層はなんでもいい
- 状態の切り離し・管理とコンポーネント化を推し進めた設計が優れていたのであり、React, Reduxであるから無批判に良いというわけではない
  - React, Reduxにも問題はある
    - propsバケツリレーつらい問題
    - Reduxの非同期処理いけてない問題
    - React, ReduxそのものはStateとComponentをどう構造化すべきかフレームワークレベルの制約を与えてない(ドキュメントに指針はある Usage with React | Redux)
SPAであることが重要なのではなく、フロントエンドを複雑なGUI環境としてとらえる視点が重要ではないか
- 自由度の高いUIを実装するには状態管理の制約とコンポーネント化があったほうが効率が良い
- 要件で必要とされるUIの自由度によって適切な手段を選ぶべき
  - 自由度が低いなら今までどおりjQueryでもスケールする要件はある
  - 境界がどこにあるかは不明