【シリコンバレーMeetupレポート】Integrating D3 & React, Navigating the React Ecosystem

# これは何？

5/24にMountain Viewで開催された Meetup "[Integrating D3 & React, Navigating the React Ecosystem](https://www.meetup.com/modernweb/events/239003827/)" に参加したのでそのレポート。

大きめの海外カンファレンスレポートはよく見るけど、「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はある](https://www.npmjs.com/package/semiotic)のだが、repositoryは消滅していた。ちょうど大幅な設計変更とかやっているんだろうと、好意的に捉えておく。（これが出来ると確かに便利なので）

# Navigating the React Solar System

Eventbriteでエンジニアリングマネージャーを務めている Ben による React の紹介。Reactを取り巻くフロントエンド開発に欠かせないフレームワークの紹介。Reactを太陽、関連ツール類を他の惑星に見立て、React 太陽系という感じで紹介していた。

[プレゼンスライド](http://www.benmvp.com/slides/2017/modernweb/nav-react.html#/)公開されているので、興味のある方はチェックしてみてください。

本レポートでは、React以外の他のツールについて紹介。

## React Dev Tools

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/a358f530-e2ef-b8cb-c82b-39786815f5ff.png)

chrome や FireFox の extension として利用可能。これを入れるとJSXの状態でのデバッグができる（これ入れないと、``div`` なんかに展開された Element treeしか見れないので、かなりつらい）。

あと、[Redux DevTools](https://chrome.google.com/webstore/detail/redux-devtools/lmhkpmbekcpmknklioeibfkpmmfibljd) もおすすめ。Reduxの状態遷移なんかをリアルタイムに確認できる。これチョー便利。

## パッケージマネージャー：yarn


![image](https://qiita-image-store.s3.amazonaws.com/0/83466/199093f1-99c3-d9c9-7c1e-0b297a22b5dd.png)


better npmのyarn。特徴としては、npmと同じ操作性でより優れたパッケージ管理をしてくれる。（筆者も最近はnpmからyarnに移行している）

```bash
$ yarn install
```

をすると、npm 同様 ``package.json`` に書かれたモジュールがインストールされるのだが、この時 ``yarn.lock`` というファイルを生成してくれる。これには、インストールしたモジュールのバージョンが記述されていて、他の環境で yarn install すると、ここに記述されているバージョンのモジュールがインストールされる（なので、``.gitignore``に入れるのは bad practice）。これにより、依存ライブラリのバージョン違いによる不具合事象をなくすことができる（deploy あるある回避）。

あと、インストールされたモジュールは cache 保存されるため、他のプロジェクトやプロジェクトの再構築なんかしたときに、モジュールインストール作業を高速化してくれるし、オフラインでの yarn install なんかも可能になる。最近は、babelとかとかのお陰でこの時間は無視できないものになっているので、かなり助かる。

あと、CIを回すときの時間短縮にもつながる。

## バンドラー：webpack2

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/43b55ec1-2b04-dd8e-f182-0128ea98d0b8.png)

Bundlerといえば、webpack2が大定番。プレゼンでは Tree-Shaking を紹介。 ``import`` 構文で書いた場合、bundle時にロードしていない関数は除外してくれる。bundle ファイルのサイズを抑制。他にも bundle ファイルのチャンクとか。最近は何も考えないとbundleファイルがどんどん肥大化するので、webpack2がホント便利。

## Task runners : npm

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/c92878dc-71ce-d160-2bc4-0b3313b00df6.png)

タスクランナーでは、もはやgruntやgulpでは無く、npm/yarnの ``scripts`` プロパティで書くのが定番。webpack がall in oneのバンドラーとして存在しているからこそだが、各タスクをそれぞれコマンドラインとして記述。実に分かりやすい。

## 静的解析：flow

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/a5a797fc-e76b-68bc-6a8b-c3d0ead94af7.png)

型解析と言えば、type scriptが定番だが、ここでは flow を紹介。自動型推定してくれるので、対象ファイル先頭に

```js
// @flow
```

と書いておくだけで、かなりの部分をカジュアルにやってくれる。もちろん

```js
function square(n: number): number {
  return n * n;
}
```

ときちんと宣言することも可能。既存のESプロジェクトにAdd hockに追加することができる。flowは今まで使っていなかったので、試してみようかなって思ってる。

## Create React App

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/b0f1223a-5a5b-8651-4abd-54c86ee4f4bd.png)

Reactでハードルが高いのは、プロジェクト始めるにあたって準備がやたら必要なこと。babelやらreactやらモジュールインストールして、webpack設定して、eslintも・・・・と泣きそうになる。で、この辺を自動構築してくれるのが ``create-react-app`` 

個人的には、単体の React component 作るときはいいと思うけど、ちゃんとした SPA 作ろうとすると、さらに  React router やら redux やら入れて・・・となるので、更に一手間必要になる。この辺もカバーしてくれる boilerplate が色々あるので、この辺の活用も一考するといいと思う。筆者はもっぱら [react-redux-starter-kit](https://github.com/davezuko/react-redux-starter-kit) を使っているが、
![image](https://qiita-image-store.s3.amazonaws.com/0/83466/7a78d5e8-255c-117b-8d63-a30970638f4b.png)
結構気に入っている（わりあい、light weightなので）。templateに従って、記述していくと React & Redux のモジュラリティが高いコードが best practice に則って作れる。react router や redux の知識が要求されるため学習コストは高めだが、分かるとすごい便利。（これのcode readした時に、reduxの使い方分かってなかったんだなーと猛反省した）

## CSS Modules

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/31ac9223-25a1-9df4-d27d-941b27bf6969.png)

これなかなか面白い。SaSSのファイルをモジュールとして import し、JSX に ``className={{css.title}}`` とかとかで入れていくと、自動でname spaceも考慮した独立のCSSとして React Componentにあててくれる。
![image](https://qiita-image-store.s3.amazonaws.com/0/83466/68a41200-47b5-06ef-e35e-9a858cb8503f.png)
CSSも含めたコンポーネントモジュールを実現できる。

他にも、jsでcssをliteral定義し、 inline で入れることもできるが、これだと responsive webなんかへの対応が厳しくなる。

まぁページの一貫性として統一感をもたせるところは global CSS として定義し、各コンポーネント固有のところは CSS Modules で定義するのがいいんだろうな。。。。とは思う。CSS のほうが js よりも設計難しいよね。一貫性とモジュール性の両方を考え、全体最適しなきゃならないんだから

## Single Page App : React Router

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/283414cb-cdc4-e09a-5c90-ab5733ab635b.png)

言わずもがなの React Router。SPAならこれ一択（対抗となるフレームワークが思いつかなかったｗって言ってた）。筆者も使ってるけど、まじで便利。

## Testing : Jest

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/d25a95c5-8c15-ccea-18b2-e7ac468fd5f3.png)

testing framework としては、Jest を紹介していた。この辺に来ると駆け足だったのであれだけど、JSXのtestなんかに確かに良さげ

## Performance & SEO : Server side rendering

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/1c463a56-75f9-d173-1df6-854457eac10f.png)

React Routerで書いておいて、サーバーサイドレンダリングも忘れずに。1st viewの高速化はもちろんだが、何よりもSEOに優れる。（各ページがSPAでフロントエンドで処理されると、なーーーーんにもクローリングされなくなっちゃうので）

## Data Management

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/3f8569ab-78b2-b757-97aa-002c9db04a8c.png)

まぁ、これはReduxだよね。。。。ということで

## API Optimization

![image](https://qiita-image-store.s3.amazonaws.com/0/83466/4a1d61ef-2109-1e0d-65b2-2aab8f6878c7.png)

ここも完全に駆け足だったので、補足。最近の傾向として、複数の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のアーキテクチャを見直し、より高速化を図っているとのこと。