---
title: "React Routerのaction・loaderの使い方｜clientAction/clientLoaderの違いとv8対応"
url: "https://www.issoh.co.jp/tech/details/4436/"
published: 2024-12-09
updated: 2026-07-23
categories: ["React"]
publisher: "株式会社一創"
---
# React Routerのaction・loaderの使い方｜clientAction/clientLoaderの違いとv8対応
React Routerでデータを読むのが `loader`、書き込むのが `action` です。名前が似た `clientLoader` と `clientAction` はブラウザ側で動く別物で、どちらを書くかでSSRの挙動もバンドルサイズも変わります。この記事では4つのAPIの実行タイミングと使い分けを実コードで整理し、2026年6月17日にリリースされたv8で `context` と `url` 引数がどう変わったかまで踏み込みます。
## まとめ：actionとloaderの役割分担
- `loader`＝読み取り、`action`＝書き込み。`action` が完了すると、ページ上の全 `loader` データが自動で再検証される
- `loader` と `action` はサーバ専用でクライアントバンドルから除去される。DBクライアントやAPIキーをそのまま書いてよい
- `clientLoader` / `clientAction` はブラウザ専用。両方定義した場合、書き込みは `clientAction` が優先される
- 型は手書きせず、フレームワークモードのtypegenが出す `Route.LoaderArgs` / `Route.ComponentProps` を使う
- npmの最新は 8.3.0（2026年7月22日公開）。v8ではmiddlewareが既定になり、`context` は常に `RouterContextProvider` になった
以下、4つのAPIの境界線から順に見ていきます。
## loaderとclientLoaderの実行タイミングの違い
### サーバだけで動くloaderとRoute.LoaderArgs
公式ドキュメントは `loader` について「クライアントバンドルから削除されるため、ブラウザに含まれる心配なくサーバ専用APIを使える」と明記しています。初回表示ではサーバ（またはプリレンダリング時のビルド）で実行され、クライアント遷移のときはReact Router自身が自動で `fetch` を投げて呼び出します。つまり遷移のたびにネットワーク往復が1回発生する前提で設計します。
```
// app/routes/product.tsx
import type { Route } from "./+types/product";
export async function loader({ params }: Route.LoaderArgs) {
// DB接続やAPIキーを直接書ける（ブラウザには出力されない）
return db.getProduct(params.pid);
}
export default function Product({ loaderData }: Route.ComponentProps) {
return {loaderData.name}
;
}
```
戻り値は `Response` でなくプレーンなオブジェクトで構いません。コンポーネントは `useLoaderData` を呼ばず、props の `loaderData` で受け取るのがフレームワークモードの標準形です。
### ブラウザで動くclientLoaderとHydrateFallback
`clientLoader` はブラウザだけで実行されます。SPAとして組む場合や、ログイン後にしか呼べない外部APIを叩く場合はこちらです。初回ロード時、ルートコンポーネントは `clientLoader` の完了後にしか描画されません。その間に何も出さないと画面が空になるため、`HydrateFallback` を同じファイルからexportします。
```
export async function clientLoader({ params }: Route.ClientLoaderArgs) {
const res = await fetch("/api/products/" + params.pid);
return res.json();
}
export function HydrateFallback() {
return 読み込み中です
;
}
```
`loader` と `clientLoader` を両方書いたうえで、初回ハイドレーション時にも `clientLoader` を走らせたいときは `clientLoader.hydrate = true as const;` を追加します。`as const` は型推論のために必要で、省くと `loaderData` の型が崩れます。
### 両方定義したときの既定動作とserverLoaderによる合成
両方をexportした場合の既定動作は「初回SSR（またはプリレンダリング）は `loader`、以降のクライアント遷移は `clientLoader`」です。`clientLoader` の引数には `serverLoader` が渡るので、サーバのデータを取り直しつつブラウザ固有の情報を足す、といった合成ができます。
```
export async function clientLoader({ params, serverLoader }: Route.ClientLoaderArgs) {
const server = await serverLoader();
const stock = await fetch("/api/stock/" + params.pid).then((r) => r.json());
return { ...server, ...stock };
}
```
この合成は便利ですが、`serverLoader()` を呼んだ時点でサーバ往復が発生します。在庫数のように更新頻度が高い一部フィールドだけをブラウザで取り直す用途に限定し、ページ全体のデータ取得を `clientLoader` に移すのは避けてください。ルーティングそのものの書き方から確認したい場合は、[React Routerの基本ルーティングとmeta・title設定](/tech/details/7618/)を先に押さえると全体像がつかめます。
## actionとclientActionによるデータ更新と自動再検証
### Formからactionを呼ぶ最小構成
`action` はサーバ側でのデータ更新を担当します。`
);
}
```
ここで効いてくるのが自動再検証です。公式ドキュメントは「actionが完了すると、ページ上の全loaderデータが再検証され、コードを一切書かなくてもUIがデータと同期する」と説明しています。更新後に一覧を手で再取得するコードは不要で、書いてしまうと二重リクエストになります。特定のルートだけ再検証を止めたいときは、そのルートに `shouldRevalidate` をexportします。
### clientActionが優先されるルールと使いどころ
`clientAction` はブラウザだけで実行され、**`action` と両方定義されている場合は `clientAction` が優先されます**。この優先順位を知らずに両方書くと、サーバ側の更新処理が呼ばれない事故になります。
```
export async function clientAction({ request }: Route.ClientActionArgs) {
const formData = await request.formData();
await someApi.updateProject({ title: formData.get("title") });
return { ok: true };
}
```
使うべき場面ははっきりしています。localStorageやIndexedDBの更新、ブラウザにしか置いていないトークンで直接叩く外部API、そしてSPAモードでサーバ処理そのものが存在しない構成です。逆に、決済・在庫引き当て・権限変更といった改ざんされて困る処理を `clientAction` だけで完結させるのは設計ミスです。入力値の検証も更新もブラウザ側にあるため、DevToolsから任意のリクエストを送られれば素通りします。
### Form・useSubmit・useFetcherの使い分け基準
呼び出し方は3通りあり、判断軸は「画面遷移させたいか」の1点です。`