【実務・中級編】 カスタムフックへの副作用の抽出 – React実践ガイド

やあ、元気にしてるか？ 今日はReactのコンポーネント開発で、多くのエンジニアが一度は頭を抱えるであろう「`useEffect`の沼」から抜け出すための強力な武器、カスタムフックへの副作用の抽出について、とことん深掘りしていこう。

君たちも日々、Reactアプリケーションと格闘している中で、コンポーネントのロジックが肥大化し、`useEffect`の中に様々な関心事がごちゃ混ぜになって、

「あれ、この`useEffect`は何のために動いてるんだっけ…？」
「このイベントリスナー、ちゃんとクリーンアップされてるのかな…？」
「同じような処理、また別のコンポーネントでも書いてる気がする…」

なんて、心の中で呟いた経験があるんじゃないか？ まさに、俺も若かりし頃は同じ悩みを抱えていた。だが、心配はいらない。この「魔窟」から抜け出し、コンポーネントを美しく、そして堅牢に保つための道筋を、今日は伝授しよう。

`useEffect`、その光と影

まずは基本に立ち返ろう。`useEffect`は、Reactコンポーネントがレンダリングされた後に、そのコンポーネントの「外の世界」と同期を取るための、非常に強力なフックだ。データフェッチ、イベントリスナーの登録、DOMの直接操作、タイマーの設定など、Reactの宣言的なUIの外側で発生するあらゆる「副作用」を管理するために存在する。

ブラウザの視点から見ると、ReactがDOMを更新した後、ブラウザは再ペイントを行う。その一連の流れの中で、`useEffect`に記述されたコールバック関数が実行されるんだ。これにより、例えばAPIからデータを取得してUIを更新したり、外部のライブラリと連携したりといった、動的な振る舞いをアプリケーションに持たせることができる。

しかし、その強力さゆえに、使い方を誤るとたちまちコンポーネントの複雑性を跳ね上げてしまう諸刃の剣でもある。

• 関心事の混在: 一つの`useEffect`の中に、データフェッチ、イベントリスナー、DOM操作など、複数の異なる関心事が詰め込まれる。
• 巨大化するコンポーネント: 副作用ロジックがコンポーネント本体の大部分を占め、UIのレンダリングロジックが埋もれてしまう。
• 再利用性の欠如: 同じような副作用のパターンが、異なるコンポーネントでコピペされ、保守が困難になる。
• 依存配列の罠: 依存配列の管理を誤ると、無限ループや古いStateの参照（クロージャの問題）、不要な再実行に繋がる。そして、クリーンアップ関数の忘れは、メモリリークや意図しない挙動を引き起こす。

これらの問題は、まさに現場の泥臭さそのものだ。だが、これを解決する美しい設計手法が、カスタムフックへの副作用の抽出なんだ。

カスタムフックへの抽出、その本質とは？

カスタムフックは、Reactのフック（`useState`、`useEffect`、`useContext`など）を組み合わせた、独自のロジックを持つ関数だ。その名前が示す通り、`use`で始まる命名規則が必須で、これによりReactのフックのルール（コンポーネントのトップレベルか、他のカスタムフックのトップレベルでしか呼び出せない）が適用される。

単なるユーティリティ関数と何が違うのかって？ カスタムフックは、その内部でStateやEffectを「持つ」ことができる点、そしてそれらのライフサイクルが呼び出し元のコンポーネントと同期する点において、普通の関数とは一線を画す。これにより、Stateフルなロジックを再利用可能な形でカプセル化できるんだ。

カスタムフックに副作用を抽出することのメリットは計り知れない。

1. 関心事の明確な分離

最も大きなメリットはこれだ。コンポーネントはUIのレンダリングと、そのUIがどのように振る舞うかという「本質的なロジック」に集中できるようになる。データフェッチやイベントリスナーの登録・解除といった副作用は、それぞれのカスタムフックに責任を持たせる。これにより、コンポーネントの可読性は劇的に向上し、「このコンポーネントは何をしているのか」が一目で理解できるようになる。

2. ロジックの再利用性の向上

同じ副作用ロジックを複数のコンポーネントで必要とする場合、カスタムフックとして一度定義してしまえば、あとは呼び出すだけで済む。これは、DRY (Don’t Repeat Yourself) 原則の究極の実践であり、開発効率と保守性を飛躍的に向上させる。

3. テスト容易性の向上

副作用ロジックがカスタムフックとして独立することで、そのロジック単体をユニットテストできるようになる。コンポーネント全体をレンダリングせずに、特定の振る舞いを検証できるため、テストの記述も実行も容易になるんだ。

4. 依存配列とクリーンアップの管理が楽になる

カスタムフックの内部で`useEffect`を使うことで、そのフックの利用者は依存配列やクリーンアップ関数の詳細を意識する必要がなくなる。カスタムフックの作者が責任を持って管理するため、利用者はシンプルに「このフックを使えば、この副作用が安全に扱われる」と信頼できるわけだ。

実践！カスタムフックで副作用を制御する

それでは、具体的なコードで見ていこう。今回は「要素のクリックを監視し、そのクリック数をカウントする」というシナリオを例に取ってみよう。

悪い例: `useEffect`が肥大化したコンポーネント

まずは、カスタムフックを使わないで、全てのロジックをコンポーネント内に詰め込んだ例だ。

import React, { useState, useEffect, useRef } from ‘react’;

function MyClickCounterComponent() {
const [clickCount, setClickCount] = useState(0);
const [data, setData] = useState(null); // 仮のデータフェッチのState
const [isLoading, setIsLoading] = useState(false); // 仮のデータフェッチのState
const buttonRef = useRef(null);

// 例1: イベントリスナーの登録と解除（クリックカウント）
useEffect(() => {
const buttonElement = buttonRef.current;
if (!buttonElement) return;

const handleClick = () => {
setClickCount((prevCount) => prevCount + 1);
};

buttonElement.addEventListener(‘click’, handleClick);

// クリーンアップ関数
return () => {
buttonElement.removeEventListener(‘click’, handleClick);
};
}, [buttonRef]); // buttonRef.currentが変化する可能性は低いが、依存配列に含める

// 例2: 外部APIからのデータフェッチ
useEffect(() => {
const fetchData = async () => {
setIsLoading(true);
try {
const response = await fetch(‘https://api.example.com/data’); // 仮のAPIエンドポイント
const result = await response.json();
setData(result);
} catch (error) {
console.error(‘データフェッチに失敗しました:’, error);
} finally {
setIsLoading(false);
}
};
fetchData();
}, []); // 初回マウント時のみ実行

// 例3: タイマー設定とクリア
useEffect(() => {
const timerId = setTimeout(() => {
console.log(‘5秒経過しました！’);
}, 5000);

// クリーンアップ関数
return () => {
clearTimeout(timerId);
};
}, []); // 初回マウント時のみ実行

if (isLoading) {
return

;
}

return (

{JSON.stringify(data, null, 2)}

);
}

export default MyClickCounterComponent;

どうだ？ このコードを見て、君はどう思う？

• 一つのコンポーネントの中に、クリックイベント、データフェッチ、タイマーという全く異なる3つの関心事が混在している。
• `useEffect`が3つも並び、それぞれが何をしているのかを追うのが手間だ。
• もし別のコンポーネントでも似たような「クリックカウント」機能が必要になったら、また同じような`useEffect`を書くことになる。
• `buttonRef`の依存配列への追加なども、細かな考慮が必要になる。

これこそが、俺が「`useEffect`の沼」と呼ぶ状態だ。

良い例: カスタムフックに抽出したコンポーネント

次に、上記の副作用ロジックをカスタムフックに切り出した例を見てみよう。

1. `useClickCounter`カスタムフックの作成

まずは、クリックカウントのロジックを抜き出す。

// hooks/useClickCounter.js
import { useState, useEffect, useRef } from ‘react’;

/

• 指定されたDOM要素のクリック数をカウントするカスタムフック
• @param {React.RefObject} targetRef – クリックイベントを監視するDOM要素へのref
• @returns {number} – クリックされた回数

/
function useClickCounter(targetRef) {
// クリック数を保持するState
const [clickCount, setClickCount] = useState(0);

// targetRefが変更された時、またはコンポーネントのマウント/アンマウント時にイベントリスナーを管理
useEffect(() => {
const targetElement = targetRef.current; // refからDOM要素を取得

// DOM要素が存在しない場合は何もしない（まだレンダリングされていない可能性やrefが設定されていない場合）
if (!targetElement) {
console.warn(‘useClickCounter: targetRef.current is null or undefined.’);
return;
}

// クリックイベントハンドラ
const handleClick = () => {
setClickCount((prevCount) => prevCount + 1); // 以前のカウント値に基づいて更新
};

// DOM要素にイベントリスナーを登録
targetElement.addEventListener(‘click’, handleClick);
console.log(`useClickCounter: Click event listener added to ${targetElement.tagName}.`);

// クリーンアップ関数: コンポーネントのアンマウント時、または依存配列が変更されてEffectが再実行される時に呼ばれる
return () => {
targetElement.removeEventListener(‘click’, handleClick); // イベントリスナーを解除
console.log(`useClickCounter: Click event listener removed from ${targetElement.tagName}.`);
};
}, [targetRef]); // 依存配列にtargetRefを含めることで、refが指す要素が変わった場合にも対応

// 現在のクリック数を返す
return clickCount;
}

export default useClickCounter;

ブラウザの裏側で何が起きているか？

この`useClickCounter`フックがコンポーネントに組み込まれると、Reactがコンポーネントを初めてレンダリングし、DOMがブラウザに描画された後、`useEffect`のコールバックが実行される。

1. `targetElement.addEventListener(‘click’, handleClick);`によって、ブラウザのイベントシステムに、指定されたDOM要素へのクリックイベントが発生したら`handleClick`を実行するよう登録される。
2. ユーザーがボタンをクリックすると、ブラウザがそのイベントを検知し、登録された`handleClick`関数を呼び出す。
3. `handleClick`内で`setClickCount`が呼ばれ、Reactは`clickCount`の状態が更新されたことを知り、コンポーネントの再レンダリングをスケジュールする。
4. コンポーネントがアンマウントされる際（例えば、ユーザーが別のページに移動したり、条件付きレンダリングでコンポーネントがDOMから削除されたりする時）、`useEffect`のクリーンアップ関数が実行される。
5. `targetElement.removeEventListener(‘click’, handleClick);`が呼ばれ、ブラウザからこのイベントリスナーが安全に削除される。これにより、コンポーネントがDOMに存在しないにも関わらずイベントリスナーが残ってしまう「メモリリーク」や「意図しない挙動」を防ぐことができるんだ。

2. `useFetch`カスタムフックの作成

次に、データフェッチのロジックも抜き出す。

// hooks/useFetch.js
import { useState, useEffect } from ‘react’;

/

• 指定されたURLからデータをフェッチするカスタムフック
• @param {string} url – フェッチ対象のURL
• @returns {{data: any, isLoading: boolean, error: Error | null}} – データ、読み込み中フラグ、エラーオブジェクト

/
function useFetch(url) {
// 取得したデータを保持するState
const [data, setData] = useState(null);
// データ読み込み中かどうかを示すState
const [isLoading, setIsLoading] = useState(true);
// エラー情報を保持するState
const [error, setError] = useState(null);

useEffect(() => {
// データフェッチをキャンセルするためのAbortController
const abortController = new AbortController();
const signal = abortController.signal;

const fetchData = async () => {
setIsLoading(true); // 読み込み開始
setError(null); // エラーをリセット

try {
// fetch APIでデータを取得、signalを渡してキャンセルのサポートを追加
const response = await fetch(url, { signal });
if (!response.ok) {
// HTTPエラーレスポンスの場合
throw new Error(`HTTP error! status: ${response.status}`);
}
const json = await response.json(); // JSON形式でパース
setData(json); // データをStateにセット
} catch (err) {
// fetchが中止された場合はエラーを無視
if (err.name === ‘AbortError’) {
console.log(‘Fetch aborted’);
} else {
setError(err); // その他のエラーをStateにセット
console.error(‘Failed to fetch data:’, err);
}
} finally {
setIsLoading(false); // 読み込み終了
}
};

// URLが存在する場合のみデータフェッチを実行
if (url) {
fetchData();
} else {
setIsLoading(false); // URLがない場合は即座に読み込み終了
}

// クリーンアップ関数: コンポーネントのアンマウント時、またはURLが変更されてEffectが再実行される時に呼ばれる
return () => {
// fetch処理がまだ完了していない場合に中止する
abortController.abort();
console.log(‘useFetch: Fetch aborted on cleanup.’);
};
}, [url]); // 依存配列にurlを含める。URLが変更されるたびにデータが再フェッチされる

return { data, isLoading, error }; // データをオブジェクトとして返す
}

export default useFetch;

この`useFetch`は非常に汎用性が高く、様々なコンポーネントでAPI通信が必要な場合に重宝するだろう。

3. `useTimeout`カスタムフックの作成

タイマー処理もカスタムフックに分離する。

// hooks/useTimeout.js
import { useEffect, useRef } from ‘react’;

/

• 指定した時間後にコールバック関数を実行するカスタムフック
• コンポーネントのアンマウント時にタイマーを自動でクリアします。
• @param {Function} callback – 指定時間後に実行する関数
• @param {number | null} delay – 遅延時間（ミリ秒）。nullを設定するとタイマーは設定されない。

/
function useTimeout(callback, delay) {
// 最新のcallback関数を保持するためのref
// useEffectの依存配列にcallbackを含めると、callbackが変更されるたびにタイマーが再設定されてしまう
// そのため、useRefを使って常に最新のcallbackを参照できるようにする
const savedCallback = useRef(callback);

// callback関数が変更されたときにrefを更新
useEffect(() => {
savedCallback.current = callback;
}, [callback]);

useEffect(() => {
// delayがnullの場合はタイマーを設定しない
if (delay === null) {
return;
}

// タイマー設定関数
const tick = () => savedCallback.current();

// setTimeoutでタイマーを設定
const timerId = setTimeout(tick, delay);
console.log(`useTimeout: Timer set with delay ${delay}ms.`);

// クリーンアップ関数: コンポーネントのアンマウント時、または依存配列が変更されてEffectが再実行される時に呼ばれる
return () => {
clearTimeout(timerId); // タイマーをクリア
console.log(`useTimeout: Timer cleared.`);
};
}, [delay]); // 依存配列にはdelayのみを含める
}

export default useTimeout;

`useTimeout`フックにおける`useRef`の使い方は、特に重要だ。`callback`関数を`useEffect`の依存配列に含めると、`callback`がクロージャによって再生成されるたびに`useEffect`が再実行されてしまう。これを避けるために`useRef`を使って最新の`callback`を参照することで、不要なタイマーの再設定を防ぎつつ、常に最新の関数を実行できる。これは「なるほど！」ポイントの一つだろう。

4. カスタムフックを利用するコンポーネント

最後に、これらのカスタムフックを組み合わせたコンポーネントだ。

// components/MyCleanComponent.jsx
import React, { useRef } from ‘react’;
import useClickCounter from ‘../hooks/useClickCounter’; // カスタムフックをインポート
import useFetch from ‘../hooks/useFetch’; // カスタムフックをインポート
import useTimeout from ‘../hooks/useTimeout’; // カスタムフックをインポート

function MyCleanComponent() {
const buttonRef = useRef(null);

// useClickCounterフックを使ってクリック数を取得
const clickCount = useClickCounter(buttonRef);

// useFetchフックを使ってデータを取得
const { data, isLoading, error } = useFetch(‘https://jsonplaceholder.typicode.com/todos/1’); // 仮のAPIエンドポイント

// useTimeoutフックを使って5秒後にメッセージをログ出力
useTimeout(() => {
console.log(‘MyCleanComponent: 5秒経過しました！’);
}, 5000);

// 別のタイマーで3秒後にアラート表示（例）
useTimeout(() => {
alert(‘MyCleanComponent: 3秒経過しました！’);
}, 3000);

if (isLoading) {
return

;
}

if (error) {
return

;
}

return (

);
}

export default MyCleanComponent;

どうだ？ 先ほどの「悪い例」と比べて、コンポーネント本体がどれだけスッキリしたか、一目瞭然だろう。

• `MyCleanComponent`は、もはやUIのレンダリングとそのためのデータ（`clickCount`, `data`, `isLoading`, `error`）の管理に集中している。
• 具体的な副作用ロジック（イベントリスナーの登録・解除、データフェッチ、タイマーのセット・クリア）は、それぞれのカスタムフックに完全にカプセル化されている。
• `useClickCounter(buttonRef)`のように、必要な引数を渡して、返り値を受け取るだけで、複雑な副作用ロジックを安全に利用できる。

これが、カスタムフックによる副作用抽出の真骨頂だ。

カスタムフック設計のベストプラクティス

カスタムフックを最大限に活用するためには、いくつかの設計原則がある。

1. 単一責務の原則 (Single Responsibility Principle)

一つのカスタムフックは、一つの明確な関心事のみを扱うべきだ。`useClickCounter`はクリックカウントのみ、`useFetch`はデータフェッチのみ。これにより、フックの再利用性が高まり、変更の影響範囲を最小限に抑えることができる。

2. 明確なインターフェース

カスタムフックの引数と返り値は、そのフックが何をするのか、何を返すのかを明確に伝えるべきだ。例えば、`useFetch`は`url`を引数に取り、`{ data, isLoading, error }`のようなオブジェクトを返すことで、利用者は何が手に入るのかをすぐに理解できる。

3. 命名規則の遵守 (`use`プレフィックス)

これはReactの公式ルールだが、`use`で始まる名前を必ず使うこと。これにより、Reactのリンターや開発者ツールが正しくフックを識別し、フックのルール違反を検知できるようになる。

4. 適切な抽象度

あまりにも汎用的にしすぎると使いにくくなり、逆に特定のコンポーネントに特化しすぎると再利用性が失われる。このバランスが難しいが、まずは「これ、他の場所でも使えそうだな」と感じたら、カスタムフックとして切り出すことを検討するくらいの感覚で良い。必要に応じて、より汎用的なフックの上に、特定のビジネスロジックを持つフックを構築する、といった多層的な設計も可能だ。

5. エラーハンドリングとローディング状態の考慮

外部システムとの連携を伴う副作用では、エラーやローディング状態の管理が必須だ。`useFetch`のように、フックの返り値にこれらを含めることで、利用側で適切にUIを更新できるようになる。

6. 依存配列の厳格な管理

カスタムフック内部の`useEffect`の依存配列は、フックの作者が責任を持って管理する。特に、関数を依存配列に含める必要がある場合は、`useCallback`を使って関数の安定性を保証するなどの配慮が必要になる場合もある。

まとめ

今日は、Reactにおける`useEffect`の強力さと、それが引き起こしうる問題、そしてその解決策としてのカスタムフックへの副作用の抽出について、深く掘り下げてきた。

カスタムフックは、単なるコードの整理術ではない。それは、

• コンポーネントの責務を明確にし、
• ロジックの再利用性を高め、
• テストを容易にし、
• 結果として、より堅牢で保守しやすいアプリケーションを構築するための、Reactにおける設計思想そのものだ。

君たちがこれから出会うであろう複雑な副作用の多くは、このカスタムフックの考え方を取り入れることで、驚くほどシンプルに、そして美しく解決できるはずだ。

最初は少し戸惑うかもしれない。どのロジックを切り出すべきか、どういうインターフェースにするべきか、悩むこともあるだろう。だが、試行錯誤を繰り返すことで、君自身の「カスタムフックの引き出し」がどんどん増えていくはずだ。

さあ、恐れることはない。今日の知識とコードを手に、君のReactアプリケーションを、より洗練されたものへと進化させていってほしい。現場で会うのが楽しみだ！