ずっと行こう行こうと思っていた「HTML5とか勉強会」ですが、今回はReactについてするということだったので、急いで登録して行ってきました！
まずは、イベント詳細を。
- 日 時： 2016年5月31日(火) 19:30 ~ 21:30
- 会 場： イベント＆コミュニティスペースdots.
- サイト： http://eventdots.jp/event/589181
- 動 画：
以下は、公演中にメモった内容です。あまりあてにならないので動画やスライドを見てくださいw
19:35-19:55 React現状確認 by @koba04 さん
- Reactを求める理由ってなんだっけ？
- Performance?
- ちがうよねー
- メンテナンスコストとかだよねー
- ComponentはただのFunctionとして作るのは基本
- 今はまだあまり考慮されてないけどそのうちパフォーマンスも考慮されていくはず
- es2015のclassがおすすめ
- render内にonClickみたいなバインダーは置かないほうがいいよ
- 毎回レンダリングしちゃうからね
- constructorに置いたらいいよ
- react.createClassは無くなると思う
- mixing high order components
- autobinding constractor内でやる
- pureComponent
- githubのReactの#6914のプルリクを見てね
- pops
- validationチェックに使用するpropTypesは今後ゆるやかにStaticな型ライブラリになる
- Runtimeでしか判定できない
- react-coreは軽量化傾向なので別パッケージとして外に出されそう
- State setStateがなんとかかんとか（聞き逃した・・。）
- ReactElement ただのオブジェクト すっきり
- Ref&Dom
- Context 基本は使わない
- ReduxのようなライブラリのようなAPI
- Test ShallowRender - nodeのないlocalだけでもレンダリングできるよー
- テスト用のライブラリ
- airbnb/enzyme
- testing utilities for react components
- 重要なのはShallow
- テストがわかりやすくかけるよー
- オフィシャルのテストUtilになる？
- ESLint 最高だよね 相性がいい
- ReactNative
- FacebookのFacebook.appの一部機能がこれで開発されてる
- アプリの内部で使用されてる（メインじゃなくて）
- clossOSだからいいね
- JSロジックもJSでかけるよー
- F8っていう
- Facebookのイベントにて http://makeitopen.com
- チュートリアルっぽくてよし
- react-basis tiny react renderer（github）
- レンダラー作りたくなったらこのレンダラーを読み込んだらよろし
- 最新情報 reactjs/core-notes おすすめ coreはどんどん小さくしていきたいみたい
19:55-20:15 なぜReduxを使うのか by @kuy さん（株式会社ジャパンベンチャーリサーチ）
- 解説記事も増えてきたねライブラリも充実してきたし
でも、、、
つらい、難しい、良さがわからない・・・ by Twitter
まずは、Reduxがなにかを理解しよう！
「背景のアイデアを学べ！」 by 作者
背景
- FluxViewからActionDispatcherを介してActionをStoreに送るViewはStoreから受け取ったデータをまたViewに返すViewはレンダリングする
- バケツリレー問題Storeのデータは下に伝搬させていく思想そうなると無関係なデータも通過させなくてちゃいけなくなる親のComponentが全部受け持たないといけない
→ Fluxが解決したことAction おかげでTestが容易になった
でもつらくなった。。
- ReduxDispatcherがなくなったよー（Storeに埋め込まれた）Storeはデータを持っていて、伝えるだけーで、機能を分割した
どこがいいの？
single store / single stateではなくて、1つの巨大なStateツリーを複数のReducerで管理状態管理に特化したので、それ以外は実装しないといけないStoreの役割を分解して名前をつけた
1つのStoreになったのでわかりやすいね！でも、View毎に切り出して渡す必要あり。
巨大なStore Tree。Stateはツリー構造でそれぞれReducerが割り当てられてるどんどんネストしちゃうからReducerの分割は避けたほうがいいって言われてる最初からTree作るんじゃなくて、寄せ集めて作るよ ボトムアップね 必要そうなデータをリストアップしてみて、 それぞれReducerを作って（関係は考えずに） Action作ってあげて Viewに組み込んでやる
状態管理に特化してるので、いろいろできないこともたくさん formの扱い（onChangeとかの値をいちいちStateに持っていく必要がある） こういう時はRedux用のformライブラリを使ってあげる 非同期処理もRedux-sagaとか ミドルウェアを使ったり書いたりしたらいいよ
■では実際アプリを作る際に。
combineReducers() StateとReducerは分割されてるし独立してるから他のStateが参照すらできない！ 同じAction使ってもよし、統合してもよし でも、Reducerが肥大化するのはよくない ViewにはIDとか最小限の情報を渡して、Actionを飛ばしてそこで情報を補うとか
非同期処理との戦い 起動時に初期データを読み込む悪い例 componentDidMount()で非同期処理する redux-api-middlewreを導入してみる redux-thunkを導入してみる いいんだけど、ActionCreaterが複雑になる 今のBestは「redux-saga」
まとめ 背景を理解して、ライブラリの流行り廃りに振り回されないように Reducerの分割は一筋縄ではいかないのでしっかり悩もう Reduxはミドルウェアなしには厳しいよ
20:25-20:45 Relay by @hokaccha さん
資料：https://speakerdeck.com/hokaccha/relay-1■RelayとはReactをサーバサイドに使うやつreact-relay <-> graphql-relayフルスタックなFW データストアもAPIのハンドリングもサーバ実装もやっちゃうよ
■GraphQLとはクエリ言語クライアントーサーバ感のやりとりに使うよRESTFullはエンドポイントがリソース名で、HTTPメソッド指定して投げたらJSON返ってくるけど、GraphQLは、リクエストに対してレスポンスが1：1 JSONなげてJSONが返ってくるんだけど、返すパラメタを投げたやつだけ帰ってくるような構造仕様があるよー 従来 イベント→問い合わせ→レスポンスでDOMを更新 React イベント→リクエスト→Storeに入れとけば自動でDOM更新 Relay イベント→リクエストを作ると（クエリのJSon書いてSetValueってやる感じ）勝手にリクエスト投げてVIewが更新される
クエリのJSONは階層構造だよー 大枠 ヘッダ コメントとか 階層構造の一部のデータだけを取り出して参照するみたいなやり方もできるよ
JSXもコンパイル必要だけどこれも同じで、babelReleayPlugin.jsでコンパイル型定義しておくと、その型に従ってコンパイル時に型チェックしてくれる
・Relayつらい敷居が高いGraphQLの学習コストサーバ実装が必要サンプルが少ない
・期待フルスタックなフレームワークで次世代のRailsになれそう？？とにかくつらそう。
20:45-21:05 How to style React components Quramyさん（株式会社WACUL）
ーCSSのお話ー
■Component
最近のJSフレームワークはコンポーネントつくれるReactもAngularもVueも・・・Card Componentについて考えて見る
const prop = { title, primary, children,} = this.props;return <div className=`card` {...prop}>;
表示してあげて、終わり！！
・・・本当に？
classのcardのcssをいじってしまうと簡単にComponentが壊れてしまう！！
？？CSSのセレクターはグローバルなのが問題？？そこで、 CSSの命名規則を適応しよう WEBの仕様自体を堅牢に CSS in JS CSS Modules
■CSS in JSJSで書くとDOMになる！→ React : CSS in JSJSXでhtmlを取り込めたんだからCSSもJSでReactに取り込んじゃったら？という概念class名を使わずにin-lineで書いちゃう！いろんなclassを複数重ねるよりJSのObjectでassignするほうが向いてない？使ってないclass名もESLINTで消せるしね使うときにロードすればいいし一方、in-lineスタイルでは、 before / hover セミコロン系 アットマーク系は使えなくなる
ー 頑張ってるライブラリ radium @Radiumって書くとBabelが解析してくれるよ hoverとかもonMouseイベントを乗っ取ってうまくやってくれるよ react-style jsxstyle
■CSS ModulesやっぱりJSとCSSは別に描こうよっていう思想常に外側から利用される .title { font-size: 10em };が const title = { `font-size`: 10 };ってなる感じCSSを書いて、それを読み込んで置き換えるような構造DOMに付与するときにsuffixが勝手に付与されるので外から破壊されにくい！そのままじゃ使えないからライブラリがあるよ browselify / webpackとかとかclassの拡張もできるよ composes変数も共有できるよ @value まぁそこまでなくてもいいような 代替できるしCSS単品をよみこんで変換もできる 綺麗なCSS → 汚くなったCSSとJS変数を吐き出す
■で、結局どっちがいいの？ CSSをJSで書くかCSSで書くかの違いでも、今のところはCSSはCSSで描きたいよねーっていう雰囲気なのでCSS Modulesが優勢？
21:05-21:25 Atomic Design powered by React @ AbemaTV 五藤 佑典 さん（株式会社サイバーエージェント）
資料：http://www.slideshare.net/ygoto3q/atomic-desigin-powered-by-react-abematvAbemaTVの事例紹介cyberAgent meets ASAHI TVのテレビ配信
〜Web版のフロントエンドのお話し〜
アプリ版が先行している状態で、WEBを後追いで作るUIはアプリと異なる可能性あるので適切な粒度のComponentを作り始めるAtomic Designという粒度の統一化をした・Atoms（原子） スライダー、ボタン、チェックボックスなどなど
これ以上分解できない粒度のものをAtomとする
・Molechles（分子） Atomを組み合わせたComponent 例：アイコンとボタン 例：イメージとテキスト
・Organisms（有機体） Atom＋Atom＋Molechlesのような組み合わせ
画面仕様の変更があっても粒度がある程度細くても変更がスムーズにできた！個人の感覚に依存しない！Componentの粒度決定に威力を発揮するよ
■ Atomic Design + Flux・View
React + Atomic Design データフロー用のComponent - container component データのFetch用 Atomic Design component - 表示コンポーネント レンダリングに専念させる
おかげでatomic design componentはデータ構造に依存しないようなComponentになった コンポーネントのレンダリングを確実に予想できるようにする 表示コンポーネント外部の状態に変化を与えない（Actionは表示コンポーネントからは叩かずデータcomponentから叩く、Storeデータも直接みない） コンポーネントリストでの管理をする Reactの場合は、1コンポーネントの記述量がJSXのみに限りなく近くなる → デザイナーが参入しやすい！
コンポーネントのバリデーション 一方、container componentがカオスになりやすい
0コメント