ウェブとフロントエンド · 上級
ウェブアプリでの状態管理
一行でいうと: 状態と呼ばれるもののほとんどは、間違った場所に格納されたサーバーデータだ——それらを分離すれば、複雑さの半分が消える。
四種類の状態
サーバーデータ。リスト、アイテム、プロフィール。これらはリモートの信実の源のコピーで、キャッシュ処理が必要:ローディング、リフレッシュ、期限切れ。
UIの状態。開いたパネル、選択したタブ、入力したテキスト。コンポーネントに住み、それと共に死ぬ。
アドレスの状態。フィルター、ページネーション、検索。その場所はURLだ——共有して戻れるように。
真のグローバル状態。ログインユーザー、テーマ、言語。ごく少数のもの。
よくある間違い
すべてを一つのグローバルストアに入れる。結果:すべての画面がすべての画面に依存し、データは誰も気づかずに古くなり、特定の順序で画面に到達した場合のみ現れるバグ。
分離すると、グローバルコードのほとんどが蒸発する。残るものは小さく、理解しやすい。
明示的なハンドリングが必要なもの
各取得のロードとエラー状態、より新しいものの後に戻る古いリクエストの防止、サーバーが拒否したときにロールバックする方法を知る楽観的更新。
さらに深く
データタイプごとに一つの鮮度ポリシーを定義する——コピーがどれくらい有効と見なされ、いつバックグラウンドでリフレッシュするか。明示的なポリシーなしに、各画面が独自のものを発明し、「なぜこれが更新されないのか」が永遠のバグになる。