ウェブとフロントエンド · 上級

ウェブアプリでの状態管理

一行でいうと: 状態と呼ばれるもののほとんどは、間違った場所に格納されたサーバーデータだ——それらを分離すれば、複雑さの半分が消える。

四種類の状態

サーバーデータ。リスト、アイテム、プロフィール。これらはリモートの信実の源のコピーで、キャッシュ処理が必要:ローディング、リフレッシュ、期限切れ。

UIの状態。開いたパネル、選択したタブ、入力したテキスト。コンポーネントに住み、それと共に死ぬ。

アドレスの状態。フィルター、ページネーション、検索。その場所はURLだ——共有して戻れるように。

真のグローバル状態。ログインユーザー、テーマ、言語。ごく少数のもの。

よくある間違い

すべてを一つのグローバルストアに入れる。結果:すべての画面がすべての画面に依存し、データは誰も気づかずに古くなり、特定の順序で画面に到達した場合のみ現れるバグ。

分離すると、グローバルコードのほとんどが蒸発する。残るものは小さく、理解しやすい。

明示的なハンドリングが必要なもの

各取得のロードとエラー状態、より新しいものの後に戻る古いリクエストの防止、サーバーが拒否したときにロールバックする方法を知る楽観的更新。

さらに深く

データタイプごとに一つの鮮度ポリシーを定義する——コピーがどれくらい有効と見なされ、いつバックグラウンドでリフレッシュするか。明示的なポリシーなしに、各画面が独自のものを発明し、「なぜこれが更新されないのか」が永遠のバグになる。