React / Flux を実案件で使ってみた
2015/01/14 reactsushi
React / Flux を知ったきっかけ
- mizchi さんのエントリ (あなたがReactを使うべき理由) だったと思う
- 日本語の情報はほとんど無かったが、エッジ系の人たちが騒ぎ出した & 海外で圧倒的に事例が増え出したので興味を持った
- Rendr の AirBnb が React を使い始めたことを知って決定的だと思った
実案件で適用したところ
- 業務システムのやや複雑な管理画面 (新規開発する画面)
- 他の画面は jQuery で書かれているが、新しい画面は複雑なので jQuery のままでは破綻することが予想できた
- その画面でだけ React を使うことにして、 React / Flux でトップダウンに設計 & 実装
- 設計の方法は Thinking in React と Flux の二つのチュートリアルを踏襲
開発環境
- Emacs + web-mode.el (jsx のサポートがある)
- ライブラリは React.js + 元祖 Flux (facebook の Flux 実装)
- ビルドは npm run で統一。
npm run build で browserify + reactify を叩いてビルドするタスクを定義
npm run watch でコードが更新されたら onchange で検知して再ビルドするを定義- browserify から npm モジュールが使えるので単機能の小さいライブラリを積極的に使う方針
チームにどう伝えたか
- チーム向けに導入ガイドを書いて啓蒙
- nodebrew 入れて npm install して npm run build の3ステップで使えるところまで手数を減らす
- React / Flux の概念は日本語情報を中心に簡単なリンク集を作成
- あとは画面の構造に即して画面の各コンポーネントのコードを読んでもらう
- 画面がコンポーネントに構造化されて整理され、 JSX の見た目も実際の HTML タグ構造に近いので、チームメンバーにも意外と評価が高かった
実際に使ってみてどうだったか (1)
- 富豪的にデータを更新してもレンダリングコストの心配をしなくて良いのは想像以上のメリット
- サーバサイドでテンプレートを毎回レンダリングするのと同じ感覚でクライアントのコードも書ける
- データ更新の方向が一方通行なので状態が一意に定まり、混乱しにくい (Single source of truth)
- トップダウンに画面を構造化して設計できるのも良い。自然に部品化されるので共通化が行いやすい
- モジュール志向なので browserify / webpack との親和性が高い
はまったところなど
- 最初 state と prop の使い分けが分からなかった
- HTML と微妙に属性名が違うところも少し混乱する
- アニメーションが良くわからない
- バリデーションの設計も悩んだところ
テストについて
- Jest (Jasmine ベース) で少し書いた程度
- Jasmine に不慣れなので Mocha + power-assert で書きたいが短納期で手が回らなかった
- Jest のテストの仕組みは独立性の高い Mock Heavy な設計で独特
- React によってユニットテスト可能な画面要素が増えることが期待できる。理想的には Node 上で全てのテストが書けそう
あらためて何が React / Flux の美点か
Special Thanks to
- mizchi さん
- koba04 さん
- saneyuki_s さん
- この3人がいなければ React / Flux を使っていなかったと思う。ただただ感謝。