React開発の「聖域」を守れ：なぜ `exhaustive-deps` を無効化してはいけないのか？
Reactエンジニア諸君、コードを書く際にターミナルに溢れる黄色の警告を「ただのノイズ」として無視していないだろうか？
特に `eslint-plugin-react-hooks` の `exhaustive-deps` ルール。これを `// eslint-disable-next-line` で封殺するのは、時限爆弾のタイマーを物理的に破壊しているのと同じだ。今日は、なぜこのルールがReactの生存戦略において不可欠なのか、そしてチームの生産性を極限まで高めるための「プロの作法」を伝授する。
—
1. なぜ「依存関係の記述」がReactの運命を変えるのか
Reactのフック（`useEffect`, `useCallback`, `useMemo`）における依存配列は、単なる「更新のトリガー」ではない。それは「クロージャの記憶を最新に保つための契約」である。
クロージャと「古い値」の罠
Reactの関数コンポーネントは、レンダリングのたびに実行される。`useEffect` のコールバック関数は、その特定のレンダリング時のスコープを「キャプチャ」する。依存配列に値を含めないということは、コンポーネントが更新されて新しい値（PropsやState）が生成されても、フック内のクロージャは「過去の亡霊（古い値）」を参照し続けることを意味する。
禁忌の実例：
useEffect(() => {
const timer = setInterval(() => {
console.log(count); // 常に初期値の0しか表示されない
}, 1000);
return () => clearInterval(timer);
// eslint-disable-next-line react-hooks/exhaustive-deps
// ↑ ここで依存関係をサボると、クロージャが生成時の count=0 に固着する
}, []);
この「依存関係の欠如」は、一見動いているように見えても、非同期処理やイベントリスナーの内部で致命的なバグを誘発する。これを無視するのは、エンジニアとしての怠慢であり、将来の自分に対する負債の押し付けだ。
—
2. チーム開発を加速させる「神・設定」ベストプラクティス
個人のエディタで設定を完結させるのはアマチュアだ。チームで開発速度を最大化するなら、設定は共有し、強制させる必要がある。
推奨構成：.eslintrc.js の真髄
単にルールをONにするだけでなく、エラーとして検知させ、CIで弾くのが鉄則だ。
module.exports = {
plugins: [‘react-hooks’],
rules: {
// 警告ではなく「エラー」に昇格させるのがプロの現場
‘react-hooks/rules-of-hooks’: ‘error’,
‘react-hooks/exhaustive-deps’: [‘error’, {
// カスタムフックで独自の依存関係を定義する場合の拡張設定
‘additionalHooks’: ‘(useMyCustomEffect|useAsyncEffect)’
}]
}
};
チーム共有の秘訣：Prettierとの調和
ESLintとPrettierの競合で時間を溶かすのは今日で終わりにしよう。`eslint-config-prettier` を使い、フォーマットはPrettierに、コード品質はESLintに専念させるのが鉄則だ。
—
3. 実務で生産性を爆上げする「禁断のテクニック」
プロが愛用するエディタ拡張
- ESLint (by Microsoft): 保存時に自動修正 (`fixOnSave`) を有効にするのは基本中の基本。
- WakaTime: どのファイルで時間が溶けているかを可視化する。
- GitLens: 依存関係を破壊した「犯人（過去の自分）」を瞬時に特定する。
隠れたキーボードショートカット
VS Codeの「Quick Fix (Cmd + . / Ctrl + .)」を使いこなせ。`exhaustive-deps` の警告が出た際、手動で配列を書き換えるのは非効率だ。Quick Fixを使えば、Reactが自動的に不足している依存関係を補完してくれる。 この一瞬の効率化の積み重ねが、1週間で数時間の差を生む。
—
4. アーキテクトからの提言：警告を「解決」するための思考法
もし `exhaustive-deps` の警告を消すために依存関係を増やした結果、無限ループが発生したとしたら？ それは「依存関係が間違っている」のではなく、「コンポーネント設計自体が複雑すぎる」という信号だ。
1. 値を安定させる: `useMemo` や `useCallback` で関数の参照を固定する。
2. ロジックを分離する: 依存関係が肥大化しすぎる場合は、その処理をカスタムフックに切り出し、コンポーネントの責務を小さくする。
3. `useRef` を活用する: どうしても再実行したくないが、最新値だけは参照したい場合は `useRef` でラップする。
警告は「修正すべきバグ」であると同時に、「コードの設計を見直せ」というReactからの温かい助言でもある。
—
まとめ
`eslint-plugin-react-hooks` は、単なるツールではない。Reactのレンダリングモデルという「複雑な規律」を、我々が守るための羅針盤だ。
警告を抑制するな。むしろ積極的に警告を出し、それを瞬時に解決するコードを書け。それができるエンジニアこそが、技術的負債を抱えず、高速かつ堅牢なプロダクトを産み出せる「真のリードエンジニア」である。
さあ、今すぐ `eslint-disable` を削除し、プロジェクトの「健全性」を取り戻そう。コードが美しくなれば、バグは消え、開発体験は劇的に向上するはずだ。