はじめに
react, redux周りのnpmパッケージはまさに春秋戦国じだいがごとくパッケージが乱立し、訳がわからない状態になっています。
１か月後には全然違うKPTになってるかもしれませんが、現時点をログっておいて、１か月後に差分見たい。
[2016-06-18 追記]実際めっちゃ変わった。ウケる。
あくまで個人的な KPTですので悪しからず。
でもコメントは歓迎です。いろんな人とこの辺の構成の話したい^^
前提
- サーバーサイドレンダリングは不要
- クローラーの対象になる必要がない画面なので
reactらへん
react(keep)
いろいろと(以下参照)あるけど、5年後にreactが残ってるって保障なんかないけど、fluxと合わせてstatelessに作ったreactを見てると、少なくとも今はこれで良い、って思える。
* http://anond.hatelabo.jp/20160521163144
* http://mizchi.hatenablog.com/entry/2016/05/24/100547
Stateless Functions(keep)
https://facebook.github.io/react/docs/reusable-components.html#stateless-functions
今のとこ全てのコンポーネントをfunctionで書いている。
特に困っていないのはreact-reduxのおかげだと思う。reducerを分割していればコンポーネントごとに状態を管理させたい気分にはならない。(少なくとも今のとこ)
react-bootstrap(keep)
https://react-bootstrap.github.io/
お世話になっています。
今後、コンポーネントの改造や、オレオレcssとのコラボをCSSinJSでどれだけ叶えれるかが大きな関心ごとである。
reduxらへん
redux(keep)
redux-devtoolsとかあるのが強い。
あと今の日本においてググラビリティが高い。結構大事なことだと思う。
reducer(keep)
何が起きたらstateがどう変わるのか。が書かれている。
action(keep)
イベント一覧として存在するのがいいと思っている。
画面で何が起こった、とか、ajaxが完了した、とか。
そのイベントの属性が表現されていて、それ以上のことが表現されていないことが大事だと思っている。
[2016-06-18 追記]
middlewareを使わないことでdispatchが副作用を起こさなくなるので「reducerに何させるか？」だけを意識して設計することができるようにある。
こっちにいろいろ書きました
middleware(problem)
[2016-06-18 追記]あくまで個人的にです！！
actionがイベント一覧に徹するために、actionの副作用は全てここに書かれるべきだと思っている。
[2016-06-18 追記]って思っていたけど、副作用のないreduxは設計しやすかった。こっちにいろいろ書きました
flux-standard-action(keep)
ReduxのActionのコーディング規約。reduxも推奨している。
https://github.com/acdlite/flux-standard-action
http://qiita.com/yasuhiro-okada-aktsk/items/a14f7f37262fb6cf0bf8
↑このqiitaに全てが書かれている。
こういう決まりがあると安心できる。甘えでしょうか。。。
react-redux(keep)
どこでもドア。
react世界のどこにでもstoreのstateとdispatchをつなぐことができる。
多用すると良くないことが知られている。
react-micro-container(try)
http://qiita.com/hokaccha/items/76332e9863c067522835
reduxするほどじゃない画面ならこれを試してみたい。
でもvanilla性が上るのかなぁ。
「ただfluxである」というだけで意味があるのかもしれない。参考
redux-thunk(problem)
https://www.npmjs.com/package/redux-thunk
reduxの推しメン。
actionがすごくロジックを持ってしまう気がして、採用を取りやめ、middlewareにその責任を移した。
でもファイル分けてactionではなくthunkを名乗らせればそんなに気持ち悪くない気もする。
この子がやってくれることは、actionCreatorの拡張というよりはコンテナにあるロジックを、コンテナとactionCreatorの間に切り出してくれることだと思う。
redux-promiseと併用するならワンチャンあるかも。
redux-promise(problem)
https://www.npmjs.com/package/redux-promise
後で出てくるredux-actionsと仲がいいので採用しようかとも思ったけど恐ろしくググラビリティが低い上に、READEMEも簡素で、本当恐ろしい。
ようやく得た解釈としては、「非同期でactionをdispatchしてれるけど、redux-thunkみたいにdispatcherの増殖とかはできない。」ということ。
ボタン押下 -> ボタンをdisabled -> api呼ぶ -> 結果を画面表示
みたいな同期処理と非同期処理を同時に発火させるなら、コンテナかredux-thunkで複数dispatchさせるしかない。
redux-thunk*redux-promise*async/await (try)
async/awaitなredux-promiseとredux-actionsのコラボが強い。
actionsとthunksは分ける。
actions：同期actionと非同期actionが定義されてる。
thunks：画面イベントに反応してactionをdispatchしてくれる人。
actionがロジック持っちゃうけどmiddlewareのこと知らなくても実装できる。
そしたらmiddlewareは黒子に徹する感じかな。
まだ妄想でしかないけど。。。なのでtry。
redux-saga(try)
https://yelouafi.github.io/redux-saga/index.html
ナルトの敵キャラが作ってる。
学習コスト高め。
でも日本語READMEがある
https://github.com/yelouafi/redux-saga/blob/master/README_ja.md
qiitaもいい感じ
http://qiita.com/kuy/items/716affc808ebb3e1e8ac
redux-actions(keep)
https://github.com/acdlite/redux-actions
先述したflux-standard-actionに則ってactionを定義するとき、超便利。
actionが超絶見やすくなる。
redux-action-types(keep)
https://www.npmjs.com/package/redux-action-types
actionTypeをちょっとラクして書ける。
redux-immutablejs(try)
https://github.com/indexiatech/redux-immutablejs
reducer内でだけstateがimmutableになって欲しくて使おうと思ったけど、createReducerの守備範囲がredux-actionsと被ってたので、自前で作った。
redux-form(problem)
https://github.com/erikras/redux-form
reactのform周りのリッチなエコシステム。
圧倒的ユーザー数。安心感。
でも非同期処理やバリデーションをreact世界に書くとこを推奨しているように見えるのがなんとも。。。
とはいえ今使いたい気分にならないというだけで、世の中がこっちに流れたら「え、そんなにいいの？じゃあ使っちゃおうかなぁ。。。」ってなる可能性は十分にある。十二分にある。
redux-devtools(keep)
本家サイトのREADMEの通りに実装すれば出来上がり。
https://github.com/gaearon/redux-devtools
reducerのin/outを丸裸にできる。
router関連
react-router(keep)
超絶簡単にroutingを実現しつつ、コンポーネントの責任範囲が決まってく。
ただ。。。
親Routeにコンテナを割り当てて、子Routeにpropを渡したいって時に、この辺の書き方が。。。
https://github.com/reactjs/react-router/blob/1.0.x/examples/passing-props-to-children/app.js
私の書きっぷりがおかしいだけなのかもしれないけど。
これが嫌で全てのRouteの末端にコンテナを割り当てちゃうと、react-reduxのやってはいけないに抵触すると思っている。
もうちょいこの辺のベストプラクティスを模索したい感ある。
routerのことをreactに関心させない設計もやってみたい。
react-router-redux(keep),redux-router(try)
過去記事にも書いたけど
この両者は絶賛戦争中であり、正直どっちがどんなんなのかわかっていないσ(ﾟ∀ﾟ；)ｵﾚ
詳しくはredux-routerさんのREADMEにそれぞれの特徴と課題が描いてある。
https://github.com/acdlite/redux-router#differences-with-react-router-redux
react-router-bootstrap(problem)
redux使うならいらないと思う。
actionsにreact-router-redux#push()なactionを一覧定義した方がいいかんじ。
utility
lodash, underscore(keep)
util群、こんなメソッドほしいなぁ。railsならあるのに。。。。が大抵ある。
「これら無しでの開発なんてありえない！」って最近まで思ってたけど、js nativeに便利メソッド増えてきて、不要論も出てきてるみたい。知らなかったああああ！
足りなきゃ使うって感じですかね。
underscore.string(keep)
stringに特化したutil群。
lodash, underscoreじゃ足りない時に使う。でも重さを考えるとリスペクトして処理パクってくるのがいいのかもなぁ。
Immutable.js(keep)
https://facebook.github.io/immutable-js/
Object.assign({},が美しくないなと感じたらこちら。
reduxもちっちゃくお勧めしている
redux-immutableとかredux-immutablejsとか使えば、簡単に導入できるはず。
axios(try)
Promiseで書けていい感じ。
reduxのチュートリアルではisomorphic-fetchが使われてるけど。。。ちょっとこの辺調べられてない。。。。
jQueryは入れたくないし。superagentはaddon使わないとPromiseで書けなそうだったので。
[2016-06-18 追記]現在はsuperagentにPromiseのaddon付けて使ってる^^;
eslint(keep)
今更eslintに言及する理由はeslint-config-airbnbにある
この子は右も左もわからない僕に道を示してくれた。本当に感謝である。
http://mae.chab.in/archives/2874
終わりに
定期的に書いていきたいけど、これ、疲れるなぁあああ！！
この記事を更新すべきなのか、別で立てるべきなのかわからんなあああああ！！