Reactを導入したいRailsエンジニアの覚書き

各フレームワークの特徴（つらみ）を整理

only jQuery

• Viewが状態を持ってしまう拡張やテストがしづらい
• DOMを指定してViewの更新処理を書くのはつらい

Backbone.js

• Viewの更新処理を手動で書かないといけないのはつらい
• ModelとView間のイベント管理が煩雑になる
• イベント地獄になりがち

2 Way Data bindingを使ったフレームワーク（AngularJS、Vue.js、Ember.jsなど）

• コンポーネント毎に状態を持つとつらい
• 大規模になってくると状態を管理するのが難しくなる
  • 単一方向データバインディング: データに対して、ビューの状態が必ず一意に決まる
  • 双方向データバインディング: データに対して、ビューの状態が一意に決まるとは限らない

refs:

• Introduction To React
• 今話題のReact.jsはどのようなWebアプリケーションに適しているか？
• あなたがReactを使うべき理由
• ReactとFluxのこと

Reactを導入するとなった場合に考慮すべきこと

Search Engine Crawlability

• server side rendering使う?
• その他のソリューションを使う？
  • AJAX クロール: ウェブマスターおよびデベロッパー向けガイド
  • BromBone

デザイナーとの協業

• jadeなどのテンプレートエンジンを使って、デザイナーがもう少し触りやすい方法を模索する
• 「協業を考えるよりデザイナーがReact覚えるほうが早いのでは」という意見もある

  • 協業を考えるよりデザイナーがReact覚えるほうが早いという気が

    — りんごちゃん (@_ringogirl) April 29, 2015

スケール可能なアーキテクチャ

• stateに依存する複数の要素を、階層構造を使わずに管理する必要がある
  • React.js 実戦投入への道
• 「Components階層間でpropsのバケツリレーになる前にFluxアーキテクチャを導入したほうがよい」

  • React.js を理解する上で重要な "Thinking in React" の抄訳になっている。あと、 Component 階層間で props のバケツリレーになる前に Flux アーキテクチャを導入した方が良いと思う。 http://t.co/pHkMYaKaUk

    — Takuto Wada (@t_wada) March 16, 2015

• 規模が大きくなる場合は、Fluxの導入を検討する必要がありそう
  • Flux実装の比較: voronianski/flux-comparison · GitHub

assets管理

• （Reactに限った話ではないが）JSのライブラリを同梱したgemを使う方式だとバージョンアップに追従しづらい
• JSはnpmのエコシステムで管理したい気持ちはあるけど、sprocketsが便利なのもわかる
• この辺を参考に適切な方法を探る必要がありそう
  • 3 ways to integrate Ruby on Rails + React + Flux
  • Sprockets再考 モダンなJSのエコシステムとRailsのより良い関係を探す

front endとback endのコードの重複

• （これもReactに限った話ではないが）front endとback endのvalidationコードなどの重複が発生しそうなのでなるべく避けたい
• Isomorphicの文脈で語られるようなこと？

規約を作った方がよさそう

• 子componentがstateを直接更新しないようにしましょう的なの
  • React.jsでPropやStateを使ってComponent間のやりとりをする
• 参考になりそう
  • Airbnb React/JSX Style Guide

入門 React ―コンポーネントベースのWebフロントエンド開発