Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
状態管理を楽にする道
Search
Kalan
December 11, 2020
1
310
状態管理を楽にする道
React HAKATAの発表資料です
Kalan
December 11, 2020
Tweet
Share
More Decks by Kalan
See All by Kalan
單頁式應用中的無障礙設計
kjj6198
0
750
選擇 Svelte 的三個理由 - JSDC
kjj6198
0
290
Svelte - 如何在前端框架中脫穎而出 | ModernWeb'21
kjj6198
0
140
Day25. 如何解析 HTML 語法
kjj6198
0
130
Day24. Svelte 如何編譯程式碼(2)
kjj6198
0
170
Svelte 如何編譯程式碼(1)
kjj6198
0
150
Day22. Svelte 經驗談
kjj6198
0
140
Day18. UI 實戰篇 - 圖片檢視器
kjj6198
0
130
Day17. UI 實戰篇 - 音樂播放器
kjj6198
0
51
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
32
1.5k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
840
Code Review Best Practice
trishagee
64
17k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
720
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
4 Signs Your Business is Dying
shpigford
180
21k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
How STYLIGHT went responsive
nonsquared
95
5.2k
Designing for humans not robots
tammielis
250
25k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
Ruby is Unlike a Banana
tanoku
97
11k
Transcript
状態管理を楽にする道 @kalanyei
自己紹介 Kalan 台湾出身 福岡在住 Twitter: @kalanyei React 開発歴五年
よくあるパータン 1. まずローディングを出す 2. useEffectでAPIを呼ぶ 3. setPost を呼んで状態を更新 4. 記事を表示する
問題点 • エラーの場合、どう対応すべきか? • Loading は loading フラグで判断ではなく postがヌルかどうかで判断する
フラグを追加! isLoading, error を追加 .catchでエラー処理する
罠 エラーになったときisLoadingがtrueのまま エラーコンポネントじゃなくLoadingが表示 されてしまう postがヌルに要注意。 Can not read property ‘content’
of null
None
仕様変更なら。。。 • APIが失敗するときに3回までretryしてね。 • ユーザーが戻るボタンを押したとき、もしAPIが終わって いないならキャンセルしてね。
さらにフラグ追加
None
エラーをリセットする必要がある
問題点 • 状態が多くなればなるほど負担がかかる • 実装を徹底的に見ないとロジックはわからない • 仕様変更があったときにコードを変更する必要がある • 変更に応じてバグが出やすくなる 状態が最初から複雑ではなく
どんどん複雑になっていく
状態が最初から複雑ではなく どんどん複雑になっていく
解決案 1 - useReducer 同じところで複数の状態を変更するとき 通常、useReducer が useState より好ましいのは、複数の値にまたがる複雑な state
ロジックがある場合や、前の state に基づいて次の state を決める必要があ る場合です。また、useReducer を使えばコールバックの代わりに dispatch を下位 コンポーネントに渡せるようになるため、複数階層にまたがって更新を発生させ るようなコンポーネントではパフォーマンスの最適化にもなります。 https://ja.reactjs.org/docs/hooks-reference.html#usereducer
None
None
None
None
改善 • 何をするのかを明示している(アクションの名前でわかる) • 実装はアクションやデータを呼ぶだけ • reducerで状態遷移を統一している • reduxはみんな使っている(かも) reducer
や actionを定義するのはちょっと面倒くさいけど。。。
解決案 2 - flag使わず、statusを使う
フラグの問題点 • if (!loading && success && !canceled) みたいなコードが発生しやすい •
新しいフラグを追加すると、状態が2^n個になる • 開発者はすべての状態を把握することが不可能になる
None
TypeScriptに優しい if (status === 'error') {}
また問題点がある • 状態遷移の制御はできない • 状態遷移はわからない
ステートマシン • 遷移(状態に入る、出るとき行う動作) • 状態 • 終了状態 image source: wiki
ちょっと似てる? • actionは遷移(push, coin) • statusは状態(locked, un-locked)
似てるけど足りないよ • 制御はできない。(completed状態になってもloading状態に入る 事ができる) • 開始、終了動作は定義していない
xstate https://github.com/davidkpiano/xstate • Actions :状態に入る、出るときするべきこと • Guards:状態遷移を条件による制御すること ステートマシンを扱えるJavaScriptのライブラリ
状態遷移を可視化する ちゃんと目で見えると議論しやすい
遷移図を定義する
None
https://xstate.js.org/viz/
React に導入! useMachine
React に導入!
None
シンプルになった!
まとめ • フラグをできるだけ抑える • フラグを使わずに、statusを定義する (TypeScriptに一緒に使うと更に効果的) • useReducerを活用する • 状態遷移図を事前に定義する
• 絵を書く • xstateみたいな状態管理ライブラリの導入を検討する
リソース • xstate: https://xstate.js.org/ • xstate visualizer • Robust User
interface with finite state machines • XStateで状態遷移を共通言語にしよう • Should I useState or useReducer
ご清聴ありがとうございました!