第65回 HTML5とか勉強会 ー React最新情報 に行ってきたメモ #html5j
Angularの人が受付してるReactの勉強会に着いたやで
— りぃ (@leader22) May 31, 2016
ちなみに、今年のHTML5 Conferenceは9/3(土)だそうです。
React現状確認 by @koba04
- React.js meetup #4が6月にあるかも
- Reactの使用例
- SFC: StatelessFunctionalComponentsがコンポーネントの基本
- MixinはなくなったのでHighOrderComponentのスタイルで機能を追加
- 新しくReact.PureComponentってのが増えるかも
- `shouldComponentUpdate()`でチューニングするのがやっぱ速い
- パフォーマンスチューニングするなら
- 定番の`react-addons-perf`
- `why-did-you-update`ってパッケージもある
- PropTypesはLegacyで、FlowやらTypeScriptを使っていく流れに
- `setState()`は基本的にはまとめて反映される(が、特定の場合にまとめられない
- `unstable_batchedUpdates()`ってのもあって、まとめて`setState()`してくれる
- StringRefもLegacyで、Refはcallbackで取るべし
- テストで使える`shallowRenderer`
- そのコンポーネントの一階層下までだけrenderしてくれる
- GitHub - airbnb/enzyme: JavaScript Testing utilities for React
- ESLint x eslint-plugin-react
- 最新情報は
あとで`tap-event-plugin`についてきく
メジャーバージョンアップすれば取り込まれるからもうすぐなくなるよ!!って言い続けてたけど、今も結局必要なままで・・。
どうなってるんですか?って聞いたけど、 @koba04 さんも知らないだそうですw
なぜReduxを使うのか by @kuy
アカウントの読みは[kai]です!
- Redux機運の高まりを感じる
- 同時によーわからんって声もきく
- Reactだけだとつらい問題があってFluxがきたがそれでもつらいのでRedux
- ReduxはFluxのStoreの債務を分割しただけ
- Reduxは複数のStoreの存在を許さない
- 代わりにReducerを複数にする
- Stateの分割の考え方はボトムアップ
- 素のReduxはオススメせず、Middlewareをあわせて使うべし
- redux-form, redux-saga, etc..
- とあるreducer内で他所ののstateが欲しくなったら、そもそもStateの構造を見直すのが吉
- 非同期するならredux-sagaがよさげ
- Reducerの分割がReduxのキモ
- Middlewareの選定も大事
うーん、やっぱりむずかしいよーーReduxーーーというのが正直なきもち。
なんか違和感がずっと残ってるのは、この発表内でもそうやったけど、
- Reduxもまだまだ試行錯誤する余地がある
- なのにReduxが界隈の唯一解として語られてる(ように見える
からなんよなー。
Relay by @hokaccha
- react-relay x graphql-relay
- データのストア、APIのハンドリングも全部やるのがRelay
- サーバーの仕様・実装まで規定する
- GraphQL
- REST/RPCと同じレイヤー
- エンドポイントは1つだけ
- RESTでは複数のリクエストが必要なところを
- クエリを組み上げ(ネスト)れば1リクエストで済む
- React.ComponentをRelayコンポーネントにして使う
- 宣言的に欲しいデータへのクエリが書ける
- Relay.QL(`ここにクエリを書く`)
- JSXみたいな記法じゃない!やった!
- でもBabel通さないと動かない意味ない\(^o^)/
- babel-relay-plugin
- 現状のRelayはつらい
- Babelもサーバーがいる
- クエリ脳に慣れない
- サンプルが少ないというか無い
Falcorと一緒で敷居の高さがすごいやんね・・・。
あと後から導入できるシロモノではないよね。
How to style React components by @Quramy
- 最近のライブラリは"コンポーネント"を作ることができる
- React.Component, Angular.module, Vue.component, etc..
- CSSは外部からの影響を受けやすい
- 子コンポーネントへも影響する可能性がある
- CSSのセレクタがグローバルなのが問題
- どうするか
- CSS in JSは、Styleオブジェクトをjsで作る
- オブジェクトなので`assign`すれば@mixinとか@extendの代替もできる
- jsなのでconstとかも使える
- ただ擬似要素・擬似クラスが使えない
- メディアクエリやキーフレームアニメーションもできない
- 一部なら、ライブラリでなんとかなるが・・
- CSS Modulesは、CSSをJSで使う
- jsでcssをimportする
- その時に独自のクラス名がつく
- webpackでロードする必要あり
- CSS Modules 所感 - morishitter blog
CSSをコンポーネントに押し込んだところでどのみちカオスなコードを生み出す未来が見えるので、おとなしく綺麗にCSSを書いたらいいのでは?と思ってしまうのは、CSSも一応書けるよっていう人種やからなんかな( ˘ω˘)スヤァ
Atomic Design powered by React @ AbemaTV by @ygoto3_
- 空気を読みながら開発スタートしたAbemaTV
- なのでいつ変更が入るかわからない
- 画面仕様が変わっても怖くないように組む必要があった
- Atomic Design | Brad Frost
- 原子 > 分子みたくコンポーネントを分解して考える
- Atomic Design を実案件に導入 - UI コンポーネントの粒度を明確化した結果と副産物 | ygoto3.com
- データに触れるコンポーネントと、表示に徹するコンポーネントに分ける
- 表示に徹する方を、AtomicDesignの要素として使う
- Actionも発行させないし、Storeのデータもさわらせない
- そうするとコンポーネントのガイドも作成可能
個人的にはさっきのCSS in JS問題でもあったようにCSSはCSSで書け派なので、こういうアプローチは割と好き。
BEMと粒度がちょっと違ったりするくらいな気がするけど、やっぱそこは設計する人のセンスに依存しちゃうんかなー。