SWRの基本概念：Stale-While-Revalidate

SWRはStale-While-Revalidateの略で、RFC 5861で定義されたHTTPキャッシュ戦略です。この戦略では、古い（キャッシュされた）データをすぐにユーザーへ提供し、その後バックグラウンドで再検証を行い、新しいデータが届いたらUIを更新します。

このアプローチは体感パフォーマンスを優先します。ユーザーはネットワークの往復を待つのではなく、データをすぐに確認できます。

従来のローディングパターンでは、画面遷移のたびにユーザーへスピナーが表示されます。SWRでは、最後に取得したデータがすぐに表示され、データが変更されていればUIがバックグラウンドで静かに更新されます。

これにより、アプリケーションは大幅に速く感じられ、ローディング状態による認知的な中断も軽減されます。

SWRは、次のタイミングでデータを自動的に再検証します。ブラウザーウィンドウが再びフォーカスを得たとき（ユーザーがタブを切り替えて戻ってきたとき）、オフライン状態からネットワーク接続が復旧したとき、明示的にmutate()が呼び出されたとき、または設定可能なrefreshIntervalタイマーが発火したときです。

これらの自動トリガーにより、開発者が再取得のロジックを手動で管理しなくても、データを最新に保てます。

SWRのキーは、いくつかの状態のいずれかになります。loading（キャッシュデータがなく、初回フェッチが進行中）、revalidating（キャッシュデータがあり、バックグラウンド更新が進行中）、error（リクエストが失敗）、success（新しいデータを利用可能）です。

これらの状態を理解すると、正確なローディングスケルトンやエラーUIを構築しやすくなります。

SWRは、リクエストキー（通常はURL文字列）をキーとするグローバルなインメモリキャッシュを管理します。同じキーをリクエストするコンポーネントは、同じキャッシュ値を取得し、同じ再検証サイクルに参加します。

この自動的な重複排除により、10個のコンポーネントが同じキーでそれぞれuseSWRを呼び出しても、ネットワークリクエストは1つだけ送信されます。

SWRは、キャッシュ管理のロジックと実際のデータ取得を分離します。fetcher関数として、キーを受け取りデータを返すasync関数を指定します。

fetcherは交換可能です。fetch、axios、graphql-request、または任意の非同期データソースを使えます。fetcherがどのように動作するかにかかわらず、SWRがキャッシュと再検証を処理します。

fetcher関数を含むvalue propを指定したSWRConfigでアプリをラップします。value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}。fetcher引数を省略したすべてのuseSWR呼び出しで、このグローバルなデフォルトが使われます。

これにより、API設定（ベースURLや認証ヘッダー）を1か所に集約でき、すべてのフック呼び出しで繰り返し指定する必要がなくなります。

従来のパターンでは、useEffect + useStateを使ってローディング、データ、エラーの状態を手動で管理します。SWRなら、1回のフック呼び出しでこれらすべてを置き換え、キャッシュ、重複排除、バックグラウンド更新、エラー時の再試行を自動的に処理できます。

コード量の削減は大きく、一般的なデータ取得コンポーネントは20行以上から3行へと短縮できます。

キーはリクエストを一意に識別します。単純なケースではURL文字列を使います。パラメーター付きのリクエストでは、配列キー[url, params]を使います。paramsには、安定したオブジェクトまたは文字列を指定します。nullを指定するとリクエストが無効になります。

適切にキーを設計すると、関連するリクエストでキャッシュエントリを共有でき、関係のないリクエスト同士が衝突することもありません。

SWRは再検証を効率的に処理します。dedupingInterval（デフォルトは2秒）により、多数のコンポーネントが同時にマウントされても、複数の再検証が同時に発生するのを防ぎます。重複排除の期間内では、キーごとに1つのリクエストだけが送信されます。

これにより、多数のコンポーネントが同じデータを取得する大規模なコンポーネントツリーで起こりやすい、サンダリングハード問題を防げます。

SWRはNext.jsを開発した企業であるVercelによって作られており、統合もシームレスです。getServerSidePropsまたはgetStaticPropsでデータを事前取得でき、SWRはクライアント上でその事前取得済みの値からハイドレーションします。

これにより、サーバーでレンダリングされた初期HTMLと、マウント時に自動で行われるクライアント側の再検証を利用でき、SSRとSWRの長所を組み合わせられます。

次のうち、デフォルトではSWRの再検証を開始しないものはどれでしょうか。

SWRはStale-While-Revalidate戦略を実装しています。キャッシュされたデータをすぐに提供し、バックグラウンドで再検証を行い、新しいデータが届いたらUIを更新します。フォーカス、再接続、mutate、ポーリングをきっかけに再検証を開始します。グローバルキャッシュはコンポーネント間のリクエストを重複排除し、fetcher関数は完全に交換可能です。

このモデルにより、データ取得コードを大幅に簡略化しながら、より速い体感パフォーマンスを実現できます。