これは何？
5/24にMountain Viewで開催された Meetup "Integrating D3 & React, Navigating the React Ecosystem" に参加したのでそのレポート。
大きめの海外カンファレンスレポートはよく見るけど、「Meetupに行ってきた」的なレポートはなかなか見ないし、シリコンバレーの動向を Qiita にあげるのも意味があるんじゃないかな・・・というモチベーションで投稿。
総括
D3 と React のコンビネーションについて、突っ込んだ話が聞けるかなーと思っていったのだが、わりとエントリー的な内容だった。とはいえ、最近のWeb開発 work flow, practiceが良くまとめられた内容となっており、俯瞰的に整理するのにとても役に立った。
D3 & React
NetflixのUIエンジニアによる、D3 & Reactに関するプレゼンがあった。Reactを使うことで、DOMの衝突問題から回避されるし、カスタムコンポーネントにより独立性の高く、かつスピーディーにフロントエンド開発が行えるが、D3のVisualization（特にAnimation処理）との相性は良くないことが紹介されました（ 既存のgraphライブラリにMapすると、Virtual DOMの管理範疇外となるので、setState() とかしても検知してくれない）。
なので、演算処理はD3で行い、Visualizationは直接 <svg> をJSXで記述するのが現在のPractice。ハッキーであるのは間違いない（D3やSVGの知識が必要となる）。で、この辺りを解決するフレームワーク開発を現在進めているとした。semiotic というもので、あとで調べてみたらnpmはあるのだが、repositoryは消滅していた。ちょうど大幅な設計変更とかやっているんだろうと、好意的に捉えておく。（これが出来ると確かに便利なので）
Navigating the React Solar System
Eventbriteでエンジニアリングマネージャーを務めている Ben による React の紹介。Reactを取り巻くフロントエンド開発に欠かせないフレームワークの紹介。Reactを太陽、関連ツール類を他の惑星に見立て、React 太陽系という感じで紹介していた。
プレゼンスライド公開されているので、興味のある方はチェックしてみてください。
本レポートでは、React以外の他のツールについて紹介。
React Dev Tools
chrome や FireFox の extension として利用可能。これを入れるとJSXの状態でのデバッグができる（これ入れないと、div なんかに展開された Element treeしか見れないので、かなりつらい）。
あと、Redux DevTools もおすすめ。Reduxの状態遷移なんかをリアルタイムに確認できる。これチョー便利。
パッケージマネージャー：yarn
better npmのyarn。特徴としては、npmと同じ操作性でより優れたパッケージ管理をしてくれる。（筆者も最近はnpmからyarnに移行している）
$ yarn install
をすると、npm 同様 package.json に書かれたモジュールがインストールされるのだが、この時 yarn.lock というファイルを生成してくれる。これには、インストールしたモジュールのバージョンが記述されていて、他の環境で yarn install すると、ここに記述されているバージョンのモジュールがインストールされる（なので、.gitignoreに入れるのは bad practice）。これにより、依存ライブラリのバージョン違いによる不具合事象をなくすことができる（deploy あるある回避）。
あと、インストールされたモジュールは cache 保存されるため、他のプロジェクトやプロジェクトの再構築なんかしたときに、モジュールインストール作業を高速化してくれるし、オフラインでの yarn install なんかも可能になる。最近は、babelとかとかのお陰でこの時間は無視できないものになっているので、かなり助かる。
あと、CIを回すときの時間短縮にもつながる。
バンドラー：webpack2
Bundlerといえば、webpack2が大定番。プレゼンでは Tree-Shaking を紹介。 import 構文で書いた場合、bundle時にロードしていない関数は除外してくれる。bundle ファイルのサイズを抑制。他にも bundle ファイルのチャンクとか。最近は何も考えないとbundleファイルがどんどん肥大化するので、webpack2がホント便利。
Task runners : npm
タスクランナーでは、もはやgruntやgulpでは無く、npm/yarnの scripts プロパティで書くのが定番。webpack がall in oneのバンドラーとして存在しているからこそだが、各タスクをそれぞれコマンドラインとして記述。実に分かりやすい。
静的解析：flow
型解析と言えば、type scriptが定番だが、ここでは flow を紹介。自動型推定してくれるので、対象ファイル先頭に
// @flow
と書いておくだけで、かなりの部分をカジュアルにやってくれる。もちろん
function square(n: number): number {
return n * n;
}
ときちんと宣言することも可能。既存のESプロジェクトにAdd hockに追加することができる。flowは今まで使っていなかったので、試してみようかなって思ってる。
Create React App
Reactでハードルが高いのは、プロジェクト始めるにあたって準備がやたら必要なこと。babelやらreactやらモジュールインストールして、webpack設定して、eslintも・・・・と泣きそうになる。で、この辺を自動構築してくれるのが create-react-app
個人的には、単体の React component 作るときはいいと思うけど、ちゃんとした SPA 作ろうとすると、さらに React router やら redux やら入れて・・・となるので、更に一手間必要になる。この辺もカバーしてくれる boilerplate が色々あるので、この辺の活用も一考するといいと思う。筆者はもっぱら react-redux-starter-kit を使っているが、
結構気に入っている（わりあい、light weightなので）。templateに従って、記述していくと React & Redux のモジュラリティが高いコードが best practice に則って作れる。react router や redux の知識が要求されるため学習コストは高めだが、分かるとすごい便利。（これのcode readした時に、reduxの使い方分かってなかったんだなーと猛反省した）
CSS Modules
これなかなか面白い。SaSSのファイルをモジュールとして import し、JSX に className={{css.title}} とかとかで入れていくと、自動でname spaceも考慮した独立のCSSとして React Componentにあててくれる。
CSSも含めたコンポーネントモジュールを実現できる。
他にも、jsでcssをliteral定義し、 inline で入れることもできるが、これだと responsive webなんかへの対応が厳しくなる。
まぁページの一貫性として統一感をもたせるところは global CSS として定義し、各コンポーネント固有のところは CSS Modules で定義するのがいいんだろうな。。。。とは思う。CSS のほうが js よりも設計難しいよね。一貫性とモジュール性の両方を考え、全体最適しなきゃならないんだから
Single Page App : React Router
言わずもがなの React Router。SPAならこれ一択（対抗となるフレームワークが思いつかなかったｗって言ってた）。筆者も使ってるけど、まじで便利。
Testing : Jest
testing framework としては、Jest を紹介していた。この辺に来ると駆け足だったのであれだけど、JSXのtestなんかに確かに良さげ
Performance & SEO : Server side rendering
React Routerで書いておいて、サーバーサイドレンダリングも忘れずに。1st viewの高速化はもちろんだが、何よりもSEOに優れる。（各ページがSPAでフロントエンドで処理されると、なーーーーんにもクローリングされなくなっちゃうので）
Data Management
まぁ、これはReduxだよね。。。。ということで
API Optimization
ここも完全に駆け足だったので、補足。最近の傾向として、複数のAPIをシーケンスに呼び出して、それらをベースにページを作るなんてケースが多い。例えば、
- 該当ユーザーのprofileをapiで呼び出し
- そのユーザーのtweetsデータをapiで呼び出し
- 各tweet idから、そのコメントを呼び出す
てな感じ。SQLで言うと、各テーブルに対し逐次 select を呼ぶのに相当する。
これ、ラボでは気にならないかもしれないけど、NW latencyが増えるにつれて、如実にUXを下げる（それぞれのAPIコールのresponseを待たなきゃならないので）。あと、それぞれのapiで不要なpropertyがゴマンとやってくるケースが多い。response の待ち時間を増やすだけ。サービスdeployした瞬間に「うわーーーーー」ってなれるパターン。
なので、一つのAPIリクエストに対して、サーバーサイドで、これら複数のAPIコールを実行して一つのレスポンスにまとめあげる・・・・というのが流行ってきている（サーバー側でやれば、遅延が少ないのでシーケンシャルコールしても影響が少ない）。あと、不要なpropertyは削除（SQLで言うと、table joinなんかに相当する考え方）。
Relayはfacebookが出しているフレームワーク。FALCORはNetflix。Apolloは、、、、知らない。最近githubが対応したので話題になった GraphQL もこの部類（プレゼン時に口頭補足していた）。
React fiber
質問ででたのは、React fiber。ReactチームがVirtual DOMのアーキテクチャを見直し、より高速化を図っているとのこと。