useEffectの迷宮から脱出せよ：カスタムフックによる副作用の「外科手術」
コンポーネントの中に`useEffect`が乱立し、依存配列の管理に頭を抱え、クリーンアップ関数の呼び出し順序に怯える……。そんな「React疲弊」を経験したことはないだろうか。
Reactの副作用制御は、一見シンプルに見えて、その実、非同期処理の競合やメモリリーク、不要な再レンダリングの温床になりやすい。今日は、ただの「ロジックの切り出し」という次元を超えた、副作用を厳密にカプセル化する設計思想について語ろうと思う。
—
なぜ「生」のuseEffectをコンポーネントに直書きしてはいけないのか
多くの開発者は`useEffect`を「ライフサイクルメソッドの代用」だと誤解している。しかし、Reactの哲学において副作用とは「外部システムとReactの状態を同期させるための橋渡し」に過ぎない。
コンポーネント内で直接`useEffect`を記述すると、以下のような「技術的負債」が雪だるま式に増えていく。
1. 認知的負荷の増大: コンポーネントが「UIを表現する責任」と「副作用を制御する責任」を同時に持ち、コードの追跡が困難になる。
2. 競合（Race Conditions）の発生: 非同期通信中にクリーンアップ関数が適切に呼ばれないと、古いレスポンスが最新の状態を上書きするという典型的なバグを生む。
3. テストの困難さ: 副作用がコンポーネントと密結合しているため、単体テストで副作用をモックすることが難しくなる。
—
堅牢なカスタムフック設計：3つの鉄則
副作用をカスタムフックに封じ込める際、私は以下の3つの原則を徹底している。
1. 「宣言的」なAPI設計
カスタムフックは、何をするかではなく「何の状態を管理するか」を露出させるべきだ。内部の実装詳細（`useEffect`の有無など）は隠蔽する。
2. クリーンアップの保証
非同期処理やイベントリスナーは、必ずクリーンアップ関数をセットで実装する。特に非同期処理のキャンセルには`AbortController`が必須だ。
3. 依存配列の「純粋化」
依存配列にオブジェクトや関数を直接入れるな。`useCallback`や`useMemo`で参照の安定性を担保し、無駄な再実行を排除する。
—
実践：競合を回避する非同期データフェッチのフック
多くの現場で散見される「中途半端なデータフェッチ」を解決する、プロダクションレベルのカスタムフック例を見てみよう。
import { useState, useEffect } from ‘react’;
/
- 競合を回避し、メモリリークを防ぐためのデータフェッチフック
/
export function useAsyncData(fetcher, dependencies = []) {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);
useEffect(() => {
// 1. AbortControllerで前回の処理を即座にキャンセルする
const controller = new AbortController();
setLoading(true);
const execute = async () => {
try {
const result = await fetcher(controller.signal);
setData(result);
setError(null);
} catch (err) {
// 2. キャンセルによるエラーは無視する
if (err.name !== ‘AbortError’) {
setError(err);
}
} finally {
setLoading(false);
}
};
execute();
// 3. クリーンアップ関数：コンポーネントアンマウント時や依存変更時に実行
return () => controller.abort();
// eslint-disable-next-line react-hooks/exhaustive-deps
}, dependencies);
return { data, loading, error };
}
この実装の「妙」
- AbortControllerの活用: コンポーネントがアンマウントされた瞬間に通信を即座に断つ。これにより、ネットワークリソースの無駄遣いと、メモリリークを確実に防ぐ。
- Race Conditionの排除: `controller.signal`を`fetcher`に渡すことで、古いリクエストが完了して状態を更新してしまう「後出しじゃんけん」を物理的に不可能にしている。
—
内部挙動から見たパフォーマンス最適化
上級エンジニアであれば、Reactのレンダリングサイクルを意識せざるを得ない。カスタムフック内部で状態を更新する際、「React 18の自動バッチング」を考慮する必要がある。
複数の状態更新（`setData`, `setLoading`, `setError`）は、React 18以降であれば自動的にバッチ処理され、1回のレンダリングにまとめられる。しかし、React 17以前や特定の非同期環境では、これらが複数のレンダリングを引き起こす可能性がある。もし極限のパフォーマンスを求めるなら、`useReducer`を使って複数の状態を1つのオブジェクトに統合し、更新をアトミックにすることを推奨する。
結論：副作用を「隔離」せよ
結局のところ、優れたアーキテクチャとは「どこに何があるか」が明確な状態だ。
コンポーネントは「UIの宣言」に専念し、副作用は「カスタムフックというブラックボックス」に閉じ込める。この分離を徹底すれば、あなたのアプリケーションは単なる「コードの寄せ集め」から、「堅牢で拡張可能なシステム」へと昇華する。
`useEffect`で悩む時間が減れば、その分、私たちは「ユーザーにとっての真の価値」を設計する時間に費やせるはずだ。さあ、今すぐあなたのプロジェクトの`useEffect`を、カスタムフックへ「外科手術」してみないか？
コメント