Download to read offline
![Result
• アプリ内で表示するまとまった情報の集合
• コンテナコンポーネント（Smart Component)で表示したい情報
• ただし、Entityへの参照しか持たない
• articless: [{article: ‘article1’}, {article: ‘article2’}, … ]
• users: [{user: ‘1’}, {user: ‘2’}, ... ]](https://image.slidesharecdn.com/reactwayateight-160422103438/85/React-way-at_eight-62-320.jpg)
React way at_eight
- 1. React way atEight 2016/04/21 @halhide
- 2. 自己紹介 • 大熊秀治(@halhide) • Sansan株式会社 •2014年1月にJOIN。もう３年目です。 • 名刺管理アプリEightのwebよろず屋です • APIからUIまで何でもやってます
- 4.
- 5. Agenda • Why React？ •How React & ride on rails？ • Componentをどう作るか（教訓） • Redux（現場からの報告）
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 19.
- 20.
- 21. React • Viewライブラリ • 小さいものを使いたかった •はまった時のworkaround見つかるか不安 • Delivery最優先のプロジェクト • （なぜredux使ったし） • 仮想DOM • 細かいDOMの差分更新を考えなくても良い • Viewの差分更新回りは苦い思い出しかない • 技術記事もググれば出てくるし、自分の観測範囲において採用しよ うかな、という話をちょいちょい耳にした • 自分が使ってみたい :smile:
- 22.
- 23.
- 24. 環境 • ビルド • ES2015で書いてbrowserify+babelでビルド •タスクランナー • gulp • ES2015を変換したり • webフォント作ったり • テスト • mocha、chai、sinon • 最近はComponentのテストに airbnb/enzyme 使い始めた • https://github.com/airbnb/enzyme • Eslint • Styleguide • sapegin/react-styleguidist
- 25. How to rideon rails? • jsのビルドに必要なソース • RAILS_ROOT/front • ビルド結果 • RAILS_ROOT/app/assets/javascripts • fingerprintの為にやってるようなもんです • ビルドが走るタイミング • 開発中 • 変更をwatchして差分ビルド • prodocutionデプロイ • railsのprecompileの前にjsのビルドを走らせる
- 26.
- 27.
- 28. railsに乗るデメリット • コンポーネントの開発するのにrailsアプリが必須 • npmとgulpで完結させたい •railsのviewがないと動作確認も厳しい • 特定のViewに依存しない共通コンポーネントを作る時に特に辛い • デザイナがローカルでデザインチェックするときにrails環境も 作らないといけない
- 29. Styleguide Driven Development（言い過ぎ） •https://github.com/sapegin/react-styleguidist • React Componentのstyleguide • 差分があったcomponentだけhot reloadで再描画 • exampleをブラウザ上で直接いじれるので、簡単な動作確認もそこで可 能 • componentのみの開発がrailsのviewと独立できた
- 30.
- 31.
- 32. それでもまだ • デザイナさんがUIをローカルでチェックしたい時にrails環境を 作らないといけない • gulpでビルドしたものを更にrailsでassetsprecompileする非効率 • 世の中知見が出てきているので、railに乗り続けるか降りるかは 再検討したい
- 33.
- 34.
- 35. 事例：画像選択コンポーネント • 要件 • 画像をローカルから選ぶ •デフォルト画像から選ぶ • 別要件で使うときに二つの 理由で使えなかった
- 36. 異なる処理がまとまっていた • 画像選択＆保存が一つの同じコンポーネントで実装されていた • 「保存」ではなく「選択」のみで十分だった •サーバへのUPは別の処理でまとめてやる要件で使えない • 画像選択コンポーネントを利用する画像保存コンポーネントと いう構成だったらよかった
- 37. 選択対象の画像が状態になっていた • デフォルト画像はComponent初期化時にサーバからDLされ、コ ンポーネントのstateで管理されていた • デフォルト画像を変えたい時にpropsで変えられない •表示対象は外から制御できるようになっているとよかった
- 38. 事例：プロフィールコンポーネント • 要件 • ユーザのプロフィール情報を表示する •自分のプロフィールの時は編集アイコンが出る • プレビューの時は最低限の情報だけ表示する • 実装
- 40. 表示と制御は分ける • フラグ制御の闇 • 見た目が同じだが、微妙に異なるものをフラグ制御で一つのコンポー ネントでコントロールしようとした •コンポーネントをそれぞれ作ってる時間もなかった • 最初はフラグはなかった • 編集用が追加され • 公開用が追加され • プレビュー用が追加され
- 42.
- 43. 再利用を阻害する • stateは極力持たない • 表示に必要な情報はpropsでコンポーネントの利用側から渡す •stateとして持つのは、コンポーネントの見た目/振る舞いを実現するた めに必要なもののみ • Ex.画像選択コンポーネント • props: 表示する画像(array) • state: 選択されている画像のindex • <ImageSelector images={images} defaultSelected={0} />
- 44.
- 45. 再利用を阻害する • アプリの動きと直接結びつく処理は持たない • コンポーネントはonXXXで各種イベントハンドラーを提供するだけ •アプリとしての動作は、propsでonXXXに設定する • Ex.画像選択コンポーネント • onSelect: 選択された画像情報を引数でもらう • uploadImages: 引数でもらった画像をサーバに保存する • <ImageSelector onSelect={uploadImages} />
- 46.
- 47. 誤った再利用を防ぐ • 表示モードの “選択”と”描画”は分ける •“見た目”が同じものをコンポーネント化しておく • アプリの状態ごとにパーツを組み合わせてコンポーネントを作 る • 編集用コンポーネント • プレビュー用コンポーネント • …用コンポーネント • アプリの状態に紐付いて適切なコンポーネントを上位コンポー ネントで”選択する”
- 48.
- 49.
- 50.
- 51.
- 52. Store = Client側のDB •例：ユーザ情報 • friendはすでに自分とフレンドに なっているか？ • /users.json で取得
- 53. • 例：article情報 • author:投稿者 •is_liked: 自分が「いいね」している かどうか • /articless.json で取得
- 54.
- 55.
- 57. 複数のAPIが返す情報に関連がある場合 • ユーザ一覧画面から’tanaka’さんにフレンド申請を出したら、ポ ストの方でもそれがUI上に反映されて欲しいですよね？ • users_reducerでfriendの値を更新 •articles_reducerでfriendの値を更新 • xxxx_reducerでfriendの値を更新 • yyyy_reducerでfriendの値を更新
- 58.
- 59.
- 60.
- 61. Entity • 情報そのもの • {id:1, name: ‘…’}, {id: ‘article1’, message: ‘xxx’} • SQLで言えば一つのレコード • entities/ 以下のreducerは一つのテーブルのデータ操作を担当す る
- 62. Result • アプリ内で表示するまとまった情報の集合 • コンテナコンポーネント（SmartComponent)で表示したい情報 • ただし、Entityへの参照しか持たない • articless: [{article: ‘article1’}, {article: ‘article2’}, … ] • users: [{user: ‘1’}, {user: ‘2’}, ... ]
- 63.
- 64. Action実行時 • FRIEND_REQUEST • entity/users_reducer •対象userのfriendを更新する • usersのresultの方はいじる必要がない • DELETE_ARTICLE • entity/articless_reducer • 対象idを削除する • articless_reducer • 対象idを削除する • resultの方では単純にリストから消すだけ
- 65. reducerの品質を上げやすい • Result、Entityと分けたことで、状態更新の処理が単純になった • オブジェクトのマージ •リストへの追加、削除 • テストも書ける
- 66.
- 67. Normalizer • APIの結果をresultとentityに変換してくれるライブラリ • https://github.com/gaearon/normalizr •直接使わずに、entityをモデルに変換するようにラップしたもの を利用
- 68.
- 69. Immutable.js • Result、Entityと分けたことで、状態更新の処理が単純になった • オブジェクトのマージ •リストへの追加、削除 • Immutable.jsの得意領域 • merge、update、add、deleteなどのオブジェクト、集合操作のAPIが定 義されている • 変更すると新しいオブジェクトになる -> Reactの差分検知と相性が良い
- 70. Immutable.Record • Entityに利用 • 許可されたカラムと、default 値を定義できるクラス •getterも定義できる • 普通のobjectのように参照で きる • get(‘message’)とかやる必要なし • どんな属性を持ちうるか悩ま ないで良い
- 71.
- 72. 夢 • Record定義から、entityのreducerを生成したり、、、 • PropTypeを生成したり、、、 •Action周りが良い感じになって、、、
- 73.
- 74.
- 75.
- 76.
- 78.
- 81.
- 82.