Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
なぜReduxを使うのか
Yuki Kodama
May 31, 2016
Programming
25
10k
なぜReduxを使うのか
Yuki Kodama
May 31, 2016
Tweet
Share
More Decks by Yuki Kodama
See All by Yuki Kodama
Reason
kuy
1
1.8k
redux-towerでルーティングを制する
kuy
4
2.7k
Should I use redux-saga or not?
kuy
2
3.8k
redux-sagaで副作用をコントロールする
kuy
4
1.4k
Rails+webpackの落ち穂拾い
kuy
0
1.5k
意地でもReduxを使う
kuy
1
520
Other Decks in Programming
See All in Programming
未経験QAの私が、よきQA(Question Asker) になっていく物語
atamaplus
0
330
NieR Re[in]carnationにおけるUnityアニメーション活用術
applibot
1
620
Hapticをカスタマイズしてみよう / ZOZO Tech Talk #6 Customize Haptic
endoumari
0
350
偏見と妄想で語るスクリプト言語としての Swift / Swift as a Scripting Language
lovee
2
270
【Qiita Night】新卒エンジニアによるSwift6与太予想
eiji127
0
180
Composing an API with Kotlin (Kotlin Dev Day 2022)
zsmb
0
280
Viteはいいぞ/Vite is Good
dojineko
1
110
microCMS × Shopifyで、ECサイトがリニューアル後急成長した話
microcms
0
470
확장 가능한 테라폼 코드 관리 (Scalable Terraform Code Management)
posquit0
1
320
iOSアプリの技術選択2022
tattn
6
2.5k
UI State Modeling 어떤게 좋을까?
laco2951
1
230
既存画面の Jetpack Composeでの書き換え: FAANSでの事例紹介 / Case study of rewriting existing screens with Jetpack Compose
horie1024
0
290
Featured
See All Featured
Three Pipe Problems
jasonvnalue
89
8.6k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
15
910
Build The Right Thing And Hit Your Dates
maggiecrowley
19
1.1k
Building an army of robots
kneath
299
40k
Designing for humans not robots
tammielis
241
23k
YesSQL, Process and Tooling at Scale
rocio
157
12k
Making Projects Easy
brettharned
98
4.3k
Making the Leap to Tech Lead
cromwellryan
113
6.9k
Automating Front-end Workflow
addyosmani
1351
200k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
498
130k
How to Ace a Technical Interview
jacobian
265
21k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_i
21
14k
Transcript
なぜReduxを使うのか @kuy / Yuki Kodama 2016.05.31 @ HTML5とか勉強会 #65
自己紹介 @kuy (カイ) / Yuki Kodama 株式会社ジャパンベンチャーリサーチ entrepedia(アントレペディア)の開発・運用 AWS, Ruby
on Rails, JavaScript (React + Redux) • redux-sagaで非同期処理と戦う • Reduxでコンポーネントを再利用する • Reduxのmiddlewareを積極的に使っていく • ・・・など Qiita の記事
Redux、人気ですね 去年の7月あたりから右肩上がり Google トレンド(2016.05.31 時点) キーワード:redux、カテゴリ:プログラミング • 解説記事が増えてきた • 周辺コミュニティが活発
• 関連ライブラリが充実している • Server Side Rendering や ReactNative の事例もちらほら Redux 導入してみようかな!
ところが・・・ ・・・Redux 大丈夫か? Twitter で見かける悲痛の声の数々 「Redux つらい・・・」 「Redux 難しい」 「イマイチ
Redux の良さがわからん」
Redux 作者、Dan氏のツイート 「背景にあるアイデアを学んで、他所に適用しよう」
順を追って理解してみる • Flux はなにを解決したのか? • Redux はなにがいいのか? • Flux の歴史に興味があれば
→ @amagitakayosiさん http://amagitakayosi.hatenablog.com/entry/2015/12/02/172453
Flux
Flux の構成要素とデータフロー データの流れは常に一方通行 Dispatcher を介して Action を Store に送ることでデータを変更する View
は Store から受け取ったデータだけを使ってレンダリングする
Flux で解決したこと • React コンポーネント階層が深くなったときのバケツリレーを回避 • コンポーネント間のデータの融通が不要になった • デバッグが容易になった ◦
redux-logger だけで原因を特定できることも多い • テストが容易になった ◦ React コンポーネントが与えられた props だけに基づいてレンダリングされる ようになる 基本的には React 単体で構築したときに困ることの解決
Redux
Redux の構成要素とデータフロー #1 1. View から Store に向けて Action が送り込まれる
Redux の構成要素とデータフロー #2 2. Store の中で待ち受けているのはReducer 受け取った Action と現在の状態から新しい State
を作り出す
Redux の構成要素とデータフロー #3 3. State が変更されたことを View に通知する
Redux の構成要素とデータフロー #4 4. 新しい State にもとづいて View が更新される
Redux と Flux の構成要素の違い Flux Redux View View Action Creator,
Action Action Creator, Action Dispatcher (Store) Store Store (State) Store Reducer Store Middleware Store Store Enhancer 登場人物が増えたように見えるけど、もともと Store の住人
Redux のどこがいいのか • Single Store、Single State ◦ 1つの巨大な State ツリーを複数の
Reducer で構築 • 状態管理に特化した ◦ それ以外は開発者に丸投げ ◦ 自分の目的に合ったスタックで開発できる、とも言える • Store の役割を分割して名前を付けた ◦ Reducer、Middleware など ◦ 役割がはっきりすると効果的なテストが書きやすくなった
Multiple Stores、Multiple States By Fluxxor 複数の Store があると Store 間のデータのやりとりに困る
React で困っていたことが再び・・・!
Single Store、Single State By Fluxxor Redux は Store も State
も1つにした どの Store の変更通知をどの View に購読させるか悩まなくなった その代わり、State から必要な部分だけ切り出す(react-redux) Store が1つになったので Store 間のやり取りは不要
Reducer による State の分割 State の階層はそのまま Reducer の階層になっている 入れ子は可能だけど推奨されていない(必要なら normalizr
などを使う)
1. 必要な State を列挙して初期 State を決める 2. 各 State を変更するのに必要そうな
Action を書く 3. 各 State に対応した Reducer を書く 分割された Reducer による State の構築 例えばブログアプリを考えると・・・ app: ユーザ名、認証情報、設定情報、・・・ posts: 記事データ、記事の順序、ページング情報、・・・ categories: カテゴリデータ tags: タグデータ 開発時の感覚としてはトップダウンではなくボトムアップ
状態管理に特化した Redux を素の状態のまま使うのはおすすめできない(学習目的は除く) • フォームを作りたいときは? → redux-form, react-redux-form • 通信処理のハンドリングはどうする?
→ redux-api-middleware, redux-thunk • 非同期処理はどこにどうやって書く? → redux-saga, redux-thunk 専用の Middleware ライブラリの導入を検討しよう 本当に必要なら Middleware を書いてみよう 無理して React、Action Creator、Reducer で実装すると後で大変です
Redux 再入門
State および Reducer の分割について combineReducers() ってどうなの?問題 State と Reducer は対応関係にあり、Reducer
は担当の State 以外は見えない。 もし Reducer で他の Reducer が担当する State が欲しくなったらどうするの? • State/Reducer の分割単位に問題がないか考えてみる ◦ 巨大な1つの Reducer にするという手もなくはない(けど、おすすめしない) • Middleware で情報を補完する ◦ Action には View が持ってる最小限の情報を持たせる ◦ Middleware でその Action をひろって改変 or 別 Action を投げて処理を継続する • Yet Another combineReducers() を模索する
State および Reducer の分割について http://bouzuya.hatenablog.com/entry/2016/05/25/235959 https://github.com/ryo33/combine-section-reducers combine-section-reducers: State 全体にも触れる combineReducers
Thanks! @bouzuya, @bokuweb17
非同期処理との戦い #1 1. 起動時に初期データを読み込む悪い例(ダメ。ゼッタイ。) • Reactコンポーネントとしての再利用性が低 くなる • もし間違って2箇所に配置したら2回読み込 まれる
• 副作用のあるコードを仕込むのは避けた方 がいい • テストどうすんの?
非同期処理との戦い #2 2. redux-api-middleware を導入 • 副作用を View から Middleware
に追い出すことに成功 • Symbol の CALL_API をキーにするという、ちょっと意味わからない仕様によって Middleware で Action を扱いにくい • API呼び出しをチェーンさせたりするのどうしよう( → Middleware 使うしか無い )
非同期処理との戦い #3 3. redux-thunk に移行 • Promise を使えばチェーンもできる • 変な
CALL_API がなくなった • 複雑な Promise の処理を Action Creator に押し込んでいいのか? • redux-thunk はほぼ Middleware と同等の ことができるのにカジュアルに使えてしまう (乱用すると危険) • テストどうすんの? • 機能追加していくとひどいことになりそうな未 来が見える
非同期処理との戦い #4 4. redux-saga に移行 ← イマココ • 非同期処理が読みやすい •
複雑な処理はどんどん分割する • テストが容易、モックを使わないとテストでき ない部分が最小限になる • やっていけそう
まとめ • 背景にあるアイデアや何を解決しようとしているのかを理解して、ライブラ リの流行り廃りに振り回されないようにしよう • Reducer の分割は一筋縄ではいかないのでしっかり悩もう • Redux には適切な
Middleware を導入しよう
Thank you!