SWRについて（初めの学び）

＜まとめ＞

SWRの領域は、フロントエンドでのデータ取得と状態管理。

結論、基礎理解としてuseEffectとfetcherを理解できたなら、SWRを使ったほうがメリットが大きい

＜変更箇所＞

useEffect+fetcherで管理していた箇所

useEffect(() => {

fetch('/api/admin/posts')

}, [])

＜SWRがやること＞

• APIを呼ぶ

useSWR('/api/admin/posts', fetcher)　

ここで、SWRは内部でfetcher('/api/admin/posts') を呼んでいる

• 取得したデータをメモリ上に保存

useSWR('/api/admin/posts', fetcher)　

メモリ上に保存（キャッシュ）していることにより、同じページに戻ったら即表示、画面遷移しても再取得しない、UXが速くなるメリットがある。

• ローディング管理

const { data, isLoading } = useSWR(...)　

初回アクセス時、キャッシュが存在しないとき、再フェッチ中はisLoadingがtrueになる。これにより、const [loading, setLoading] = useState(false)が不要になる。

• エラー管理

const { error } = useSWR(...)

fetcher 内で throw されたエラーを補足し、errorとして提供する（エラー典型例：ネットワークエラー、401/500エラー、JSONparseエラー）、これにより、try/catchをUI側に書かなくていい。

• 再フェッチ（自動）

SWR は「データが古くなりそう」と判断すると 自動で再取得。画面にもどってきたときやブラウザがフォーカスされたとき、ネットワーク復帰時、mutate()を呼んだときなど。

mutate('/api/admin/posts')

これにより、更新後に一覧を再取得が1行で書けるようになる

• 同じAPIの重複リクエスト防止

→同じkeyを使うuseSWRが複数あってもfetcher は1回しか実行されない

＜SWRがやらないこと＞

• DBアクセス

• API実装（route.ts）

• 認証/認可ロジック

• レスポンス内容の定義

＜useEffect + fetcher vs SWR 比較表＞