【テクニカル・上級編】 propsからstateへの同期とuseEffectの是非 – React実践ガイド

propsからstateへの同期という「禁断の果実」：useEffectの迷宮を脱するアーキテクチャ

Reactの現場で、開発者が最も頻繁に遭遇し、かつ最も深い沼にハマりやすいポイントがある。それが「propsの変更を検知してstateを更新する」という要件だ。

「親から渡された値が変わったら、内部のstateもリセットしたい」。一見すると正当な要求に見えるが、これを安直に `useEffect` で実装した瞬間、君のアプリケーションは「同期の不整合」という名の悪夢に引きずり込まれることになる。

今日は、Reactにおけるこのアンチパターンをどう解体し、真に堅牢なアーキテクチャへ昇華させるかを議論しよう。

—

なぜ useEffect による props-to-state の同期は「負け戦」なのか

多くのエンジニアが犯すミスは、以下のようなコードだ。

// 【アンチパターン】これぞ負け戦の典型
function UserProfile({ userId }) {
const [data, setData] = useState(null);

useEffect(() => {
// userIdが変わるたびに非同期でデータを取得する…が、
// 競合状態やレンダリングの不整合が起きる
fetchUserData(userId).then(setData);
}, [userId]);

return

{/ … /}

;
}

このコードの何が問題か？答えはシンプルだ。Reactのレンダリングサイクルと、副作用の実行タイミングが別個に存在しているからだ。

`userId` が変わると、まずコンポーネントがレンダリングされ、その後に `useEffect` が走る。もし `useEffect` が非同期処理を伴うなら、その間に別の `userId` に切り替わった場合、古いリクエストの結果が後から上書きされる「レースコンディション（競合状態）」が確実に発生する。

これを防ぐためにクリーンアップ関数でフラグを立てる手法もあるが、それは対症療法に過ぎない。根本的な解決ではないのだ。

—

解決策1：Stateを追放せよ（Derived State）

最もエレガントな解決策は、そもそも「同期」という概念を捨てることだ。propsから計算可能な値であれば、stateに保持する必要は全くない。

function UserProfile({ userId, rawData }) {
// propsから直接計算する。これなら同期ズレは物理的に不可能。
const processedData = useMemo(() => transform(rawData), [rawData]);

return

{processedData}

;
}

「いや、計算コストが高いんだ」という声が聞こえてくる。それなら `useMemo` を使えばいい。メモリを犠牲にしても、一貫性のないUIを見せるよりは100倍マシだ。

—

解決策2：Key属性による「強制再構築」

もし、どうしても「propsが変わった瞬間に内部状態を初期化したい（例：入力フォームの値をリセットする）」という要件があるなら、`useEffect` でこねくり回すのはやめよう。Reactの `key` 属性を使うのが、最も「Reactらしい」解決策だ。

// 親コンポーネント側でkeyを制御する
function Parent() {
const [userId, setUserId] = useState(1);

return (
// userIdが変わるたびにコンポーネントを再マウントする
// これにより、内部状態は完全にリセットされる

);
}

これこそが、Reactの宣言的UIの真骨頂だ。コンポーネントを「破棄して作り直す」というコストは、一見高く見えるかもしれない。しかし、複雑な同期ロジックを管理するコスト、バグを追跡する時間、そしてユーザーが感じる不自然な挙動の修正コストに比べれば、遥かに安上がりだ。

—

それでも useEffect を使うべき「唯一の例外」

唯一、`useEffect` で同期を行うことが許されるのは、「外部システムとの連携」であり、かつ「propsの変更が純粋なデータフロー外で発生する場合」だ。

例えば、ブラウザのAPI（Canvasの描画やメディアの再生制御など）を操作する場合、あるいはどうしても外部のライブラリ（Chart.jsのような非ReactなDOM操作を伴うもの）をラップする場合に限られる。

その場合でも、以下の鉄則を忘れてはならない。

1. クリーンアップ関数を徹底する: 非同期処理をキャンセルする、イベントリスナーを削除する。
2. 依存配列を完璧に管理する: `eslint-plugin-react-hooks` の警告を無視してはならない。
3. 競合状態をケアする: 実行中の非同期処理の結果を無視するためのフラグ（`let ignore = false;`）を必ず仕込むこと。

—

結論：アーキテクトとしての矜持

Reactのフロントエンド開発において、「状態（State）」は罪悪だ。持てば持つほど、管理コストとバグの温床が増える。

`useEffect` で props を監視して state を更新しようとしたら、一度立ち止まってこう自問自答してほしい。

> 「これは、コンポーネントを再マウントすることで解決できないか？」
> 「これは、計算によって導出できないか？」

泥臭い同期ロジックでコードを汚すのではなく、Reactのコンポーネントツリーの性質を理解し、宣言的に状態を定義する。これこそが、上級エンジニアと中級者の決定的な境界線だ。

君が書くその一行が、アプリケーションの寿命を決め、メンテナンスする未来の自分を救うことになる。さあ、今すぐ不要な `useEffect` を削除し、より堅牢なコードをビルドしよう。