useEffectの「if文」に潜む罠 —— Reactの再描画サイクルを支配する高度な副作用制御術
Reactの現場でコードをレビューしていると、`useEffect`の中に書かれた巨大な`if`文と遭遇することがよくある。一見、「特定の条件下でのみ副作用を走らせる」という健全なロジックに見えるかもしれない。だが、フロントエンドの深淵を覗くエンジニアなら知っているはずだ。その`if`文は、Reactの宣言的なライフサイクルを破壊し、時にメモリリークや競合状態（Race Condition）という名の爆弾を抱えることになる。
今日は、単なるマニュアルの解説を超えた、アーキテクト視点での「副作用の制御」について深掘りしていこう。
—
なぜ「useEffect内のif文」は危険なのか
多くの開発者がやりがちなのは、依存配列（Dependency Array）を意図的に空にしたり、逆に肥大化させたりして、副作用を制御しようとするアプローチだ。
useEffect(() => {
if (data.isReady) {
// 悪い例：副作用のトリガーがコンポーネントのライフサイクルと乖離している
performHeavyTask(data);
}
}, [data]); // data全体を監視しているため、無関係な変更でも評価が走る
この実装の最大の欠点は、「Reactの同期メカニズム」と「アプリケーションのロジック」が互いに干渉し合っている点にある。`data`オブジェクトが広範囲なプロパティを持つ場合、`isReady`以外のプロパティが更新されるたびに、この副作用は無駄に再評価される。ブラウザのメインスレッドを無駄に占有する、いわゆる「無駄な再計算」の温床だ。
—
依存配列の「純粋化」と副作用の分離
堅牢なアプリケーションを目指すなら、副作用のトリガーは極限まで絞り込むべきだ。依存配列には「副作用が依存する最小単位のプリミティブ値」だけを置く。これが、Reactにおけるパフォーマンス最適化の鉄則である。
推奨されるパターン：カスタムフックによるロジックの抽出
`if`文で制御するのではなく、副作用の実行条件そのものをフックの実行可否に変換するアプローチだ。
function useValidatedEffect(callback, deps, condition) {
useEffect(() => {
// 条件を満たさない場合は早期リターン
if (!condition) return;
// 非同期処理やクリーンアップが必要な場合はここで実行
const cleanup = callback();
return () => {
if (cleanup && typeof cleanup === ‘function’) cleanup();
};
}, […deps, condition]); // 条件自体を依存配列に含める
}
このアプローチの利点は、「副作用の責務」をコンポーネントの外へ追い出せることにある。コンポーネント側は「何を実行するか」に集中でき、副作用の実行条件は宣言的に記述される。
—
非同期の競合（Race Condition）を封じ込める
副作用が非同期処理（APIコール等）である場合、`if`文の制御だけでは不十分だ。ユーザーが高速でボタンを連打したり、コンポーネントがマウント/アンマウントを繰り返す状況下では、古いリクエストの結果が新しい状態を上書きしてしまう「競合」が発生する。
これを防ぐには、クリーンアップ関数内で「フラグを立てる」手法が最も安定的だ。
useEffect(() => {
let isCancelled = false; // クリーンアップ用のフラグ
const fetchData = async () => {
const result = await fetchApi(params);
// レスポンスが返ってきた時点で、既にコンポーネントが不要になっていないか確認
if (!isCancelled) {
setData(result);
}
};
fetchData();
// クリーンアップ関数は「副作用を打ち消す」ためにある
return () => {
isCancelled = true;
};
}, [params]);
このコードの美しさは、Reactのレンダリングサイクルを「信頼せず」に、副作用の「結果の有効性」を自前で管理している点にある。`if`文で制御するのは「実行の是非」だが、この手法は「結果の適用」を制御する。大規模アプリケーションにおいて、この差は致命的なバグの有無に直結する。
—
チーフアーキテクトからの提言：宣言的であることの代償
Reactの`useEffect`は、魔法ではない。ブラウザの再描画という重い処理の裏で動く、同期・非同期の管理ツールだ。
1. 副作用を極小化せよ: 可能な限り`useMemo`で計算を済ませ、`useEffect`はブラウザのAPI操作（DOM操作や外部購読）に限定する。
2. 依存配列を汚すな: 依存配列にオブジェクトや関数を置くと、参照の等価性チェックで地獄を見る。`useCallback`や`useRef`を併用し、参照を安定させること。
3. 副作用の「終わり方」を定義せよ: クリーンアップ関数を書かない`useEffect`は、未解決のメモリリークを抱えているのと同じだ。
「とりあえず動く」コードから、「計算量とメモリ効率まで考慮された」コードへ。その違いは、あなたが`useEffect`の中にある`if`文をどう飼い慣らすかによって決まる。
Reactのコードを書くことは、単なる実装ではなく、ブラウザのエンジンに対する「対話」である。この本質を忘れたとき、アプリケーションは複雑さという名の崩壊を迎えるだろう。さあ、次はあなたのコードで、この宣言的な美学を体現してほしい。
コメント