これは何？

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をシーケンスに呼び出して、それらをベースにページを作るなんてケースが多い。例えば、

1. 該当ユーザーのprofileをapiで呼び出し
2. そのユーザーのtweetsデータをapiで呼び出し
3. 各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のアーキテクチャを見直し、より高速化を図っているとのこと。