Roppongi.rb #3 で「RailsエンジニアがReactを始めてSSRとReduxを導入するまで」という発表を行いました

id:gfx です。Roppongi.rb #3 に登壇する機会をいただいたので、最近のKibelaのフロントエンドについて発表をいたしました。

RailsエンジニアがReactを始めてSSRとReduxとTypeScriptを導入するまで | bitjourney Kibela

イベントページ: Roppongi.rb #3 “Rails x Frontend-Tech” - connpass

（当日は開発中のKibelaのプレゼンテーションモードで行ったため色々不都合があり、ご迷惑をおかけしました。）

書きたいことはほぼ書ききったので特に補足することもないのですが、最近はReactにはだいぶ慣れてきて、Hypernova SSRも安定して運用できています。最初は開発が難しいのではないかという懸念もありましたが、現状はほぼ定形どおりの対応でReact componentの開発ができています。

もっとも、ブラウザ用のJSライブラリについてはNodeJS環境でimportするだけでクラッシュするものが少なくありません。これは window や document をトップレベルで参照していて、NodeJS環境ではそこでシンボルが未定義なため落ちてしまうからです。

このため次のように「とりあえずNodeJS環境でロードできるようにする（≒コンパイル時universalにする）」だけのpull-requestもいくつか送りました*1。

私を含めてこういう地道な活動を行っているSSR勢がある程度いるみたいなので、だんだんSSRしやすい環境になってきているものの、一部未対応のライブラリについてはimportは使わず、SSRで通過しない componentDidMount() でreuqireによる動的にロードに変更するなどして対応しています。

SPAにするかどうかはサービスの性質によると思いますが、一部のコンポーネントについてSSRをしていくのは、これからの「普通のウェブアプリ開発」の一部になっていくのかなという気がしています。

たとえば

などでもそのように主張されていますね。

去年のISUCON6でもコンポーネントの一部にReact SSRがあったのも記憶に新しいところです。そしてisucon6-finalは同時に、Reactの提供するAPIがあればフルスクラッチでSSRサーバを書いても100行程度ということを知らしめました。

isucon6-final/server.jsx at master · isucon/isucon6-final · GitHub

サーバーサイドとクライアントサイドで同じReact componentを描画するというのは一見すると無駄が多く複雑すぎるシステムに見えますが、やってみるとUIの描画が安定するし意外とメンテコストも高くないしそんなに悪くないなという話でした。

ReduxとTypeScriptは導入したばかりでそこまで知見はありませんが、特に不都合もなく動いてはいます。特にTypeScriptはいいですね、もう静的型付けのない素のES201xで大規模なアプリを書ける気がしません。はやく型アノテーションが標準に取り込まれてほしいなと思います。

*1:これに対して、本当にnodejsでも使えるものは「実行時universalである」といえます。UniversalJSにも分類があるというのはちょっとややこしいですね。