RailsにReact.jsを導入するのは簡単だが、既にMVCで作られているプロダクトにおいて、クライアントを分離するのは容易ではない。JSON API、Controller、CSS、jQueryなど色々問題がある。
https://qiita.com/khrtz/items/a43d58cad54af2425ced
前にこんなの書きましたが、既存のRailsサービスにJSライブラリを利用するには俯瞰した設計が足りない気がする(Railsにとっては)
よくReactを導入する事例で、Reactコンポーネントを作り、Fluxを作ればデータ取得から表示までクライアントで行うことができるけど、アプリケーション全体としてみたときどうなんだろう。RailsのViewはすでにhtml化されユーザーに届けられるが、その上で更にJSのロジックが動き始めるのは体験的にいいものではない。
提案: Server Side Rendering
最初にReactを置き換えていく場合、FluxやReduxなどのクライアントのデータフローを導入はまだはやい。SPAを作るにしてもSSRの段階を踏む方が健全っぽい。
WAFの利点をうまく使いながら、クライアントを置き換えることもできるはず。
viewのlayouts/applicationsにControllerから生成したhtml展開する。
https://github.com/khrtz/blog/blob/master/app/controllers/application_controller.rb
SSRをしてReactを書いていく分には、Rubyのテンプレートを書くのとそう大差はないはず。この段階で別途APIを作る必要も、Reduxを学習する必要もない。もちろん、まだ小さなアプリケーションでそれが簡単にできるということであればこの記事を読む必要もないが、中規模以上のRailsアプリケーションにとっては、どういうステップでクライアントを置き換えるかは考えた方がいい気がする。
フロントエンドエンジニアがAPIドキュメントなしに開発できるかというと難しい。Ruby on Railsはそういったサーバー、クライアントなど担当が区別されるような規模なチームで利用するケースは少ない気がする。なので、Railsに乗っかったほうが、チームにとって、プロダクトにとっていい場合もあると思う。
Railsの基本理念 : Railsの生みの親が掲げる8つの原則
http://postd.cc/rails-doctrine/
僕はRuby on Railsの小さなチームでも世界で通用されるようなサービスを作り上げられる思想は好きで、実際採用しているスタートアップは多い。この記事の内容とかを読むと、向き合ってみると案外悪くないなと思うこともある。
React.jsやVueでもいいが、コストを抑えつつ導入する道もある。サービスの特性やチームの規模によって導入方法を一度考えてみてはどうでしょう。
