React.jsで無駄に時間を使ったつまらないミスとハマり

React.jsで、無駄に時間を使ってしまった、つまらないミスやハマったことについてメモを残すのです。
繰り返される悲しみも、悪い夢も、きっと終わらせられる。


## jestでテスト実行するとsegmentation fault

```sh
$ npm test
...

Using Jest CLI v0.4.0
Waiting on 1 test...zsh: segmentation fault  npm test
```

実はインストール時に警告がでていたのですが、[Jest](http://facebook.github.io/jest/)は[node 0.8/0.10系にのみ対応](https://github.com/facebook/jest/blob/v0.4.0/package.json#L32)しており、0.12系で実行すると`segmentation fault`が発生します。

```sh 
$ npm install jest-cli
npm WARN package.json @ No description
npm WARN package.json @ No repository field.
npm WARN package.json @ No README data
npm WARN engine jest-cli@0.4.0: wanted: {"node":"0.8.x || 0.10.x"} (current: {"node":"0.12.1","npm":"2.5.1"})
...
```

[issue](https://github.com/facebook/jest/issues/243)によると古いjsdom(0.10.6)に依存している部分を新しいバージョンに対応させる必要があるようですが、jsdom自体の更新速度が速いのと、4.x系からnode.jsを捨ててio.js専用になってしまったのもあり、どのバージョンに上げるかで悩ましさがありそうです。

`nvm`ではなく`nodebrew`使っているので、ローカルのモジュールインストールとテスト実行時だけ0.10系に戻したりとかやっていますが、あまり有効な解決策は思いついていないのでまだ面倒です。


## syntasticでObject Rest Destructuringがエラーになる

Vimのシンタックスチェッカ[syntastic](https://github.com/scrooloose/syntastic)の話。

syntasticのデフォルトでは、JavaScriptの構文チェックに[JSHint](http://jshint.com/)を使うようになっていますが、DestructuringのようなES6構文に対応するにはesnextオプションが必要です。syntastic経由でオプション渡す方法がすぐに見つからなかったので、どのみちJSXなども使うのだからと[ESLint](http://eslint.org/)に切り替えます。

ESLintをインストール。
`babelify --experimental`なんかを使う覚悟の人は、.eslintrcの[ecmaFeatures](http://eslint.org/docs/user-guide/configuring#specifying-language-options)を全て`true`で記述してしまうと良いです。

```sh
$ npm install -g eslint
```

.vimrcのJavaScriptチェッカをeslintに変更します。

```vim:.vimrc
let g:syntastic_javascript_checkers = ['eslint']
```

ところが、[JSXのSpread Attributes](https://facebook.github.io/react/docs/jsx-spread.html)は独自拡張によりObject Rest Destructuringに対応していて、これがESLintでは`Unexpected token ...`としてエラー扱いになってしまいます。

```js
// ObjectのRest DestructuringはES7のproporsalなので非対応
// a -> "hoshimiya"
// z -> { b:"oozora", c:"arisugawa" }
var {a, ...z} = { a:"hoshimiya", b:"oozora", c:"arisugawa" };

// 配列はES6から使える
// a -> 1
// b -> [2, 3]
var [a, ...z] = [ 1, 2, 3 ];
```

そこで、Babel提供のラッパパーサである[babel-eslint](https://github.com/babel/babel-eslint)にパーサを切り替えます。

```sh
$ npm install -g babel-eslint
```

ドキュメントに従って、`.eslintrc`の`parser`に`babel-eslint`を指定します。

```json:.eslintrc
{
  "parser": "babel-eslint",
  "rules": {
    "strict": 0
  }
}
```

一応、下記のような注意書きがあるけれど、今のところ特に問題があるようには感じていません。`.eslintrc`の`ecmaFeatures`は未設定でも動作するので、もう参照していない感じがします。

> NOTE: Please note that this is experimental and may have numerous bugs. It is however successfuly linting the babel core.


## TestUtils.findRenderedDOMComponentWithTag でエラー
これはドキュメントよく読まずに使っていたのが問題ですが…

```sh
$ npm test
...

Error: Did not find exactly one match for tag:xxxxx
```

[findRenderedDOMComponentWithTag](https://facebook.github.io/react/docs/test-utils.html#findrendereddomcomponentwithtag)は結果が1件のものを探して返すメソッドで、結果複数あると上記のようなエラーで中断されます。[findRenderedDOMComponentWithClass](https://facebook.github.io/react/docs/test-utils.html#findrendereddomcomponentwithclass)なども同様。

複数要素を配列で返して欲しい場合には、[scryRenderedDOMComponentsWithTag](https://facebook.github.io/react/docs/test-utils.html#scryrendereddomcomponentswithtag)を使うのでした。


## CSSTransitionGroupを使おうとしてUncaught TypeError

```js
var ReactCssTransitionGroup = React.addons.CssTransitionGroup;
```
こんなコードを書いていたら、謎のUncaught TypeErrorが発生する事例。

> Uncaught TypeError: Cannot read property 'toUpperCase' of undefined

**Css**TransitionGroup ではなくて **CSS**TransitionGroup だという…


## reactifyを実行するとError: EMFILE

```sh
$ browserify -t reactify main.js -o bundle.js
Error: EMFILE, open '/tmp/exmaple/node_modules/react/package.json'
```

これは特に時間かかったわけではないけれど、`EMFILE(Too many open files)`なのでファイルディスクリプタの上限を`ulimit`で増やすなどして回避します。Mac OSXでは初期値が256と少なめだったので、発生しやすいかもしれません。

```sh
$ ulimit -n
256
$ ulimit -n 512
```

永続的に反映させる設定は環境ごとに異なるので、別途でご確認ください。

reactify固有の問題でもないので、内部で多めにスクリプトロードしそうな他のtransform(babelifyとかも？)を指定した場合などでも発生するかもですが、発生頻度もそんなに高いわけではないのであまり気にしていないです。

## その他

何かあったら追加します。