【ITニュース解説】Using Effects Effectively in React: Stop Misusing useEffect Once and For All

ReactのuseEffectフックは、React開発者にとって最も理解が難しい概念の一つだ。その複雑さから、人工知能（AI）でさえもuseEffectを誤って使用することがあり、結果として間違った知識が広まる原因となっている。この混乱の背景には、Reactの進化と、エフェクトに対する開発者の誤解がある。

かつてReactのコンポーネントはクラス形式で書かれており、コンポーネントのライフサイクル（生成、更新、消滅など）に対応するための特別なメソッドが用意されていた。例えば、コンポーネントが画面に表示されたときに実行するcomponentDidMountや、データが更新されたときに実行するcomponentDidUpdateなどだ。しかし、この方法では、ある一連の処理（例：データを取得して表示し、コンポーネントが非表示になったら接続を閉じる）を複数のライフサイクルメソッドに分けて記述する必要があり、コードが読みにくく、管理しにくいという欠点があった。

React 16.8で導入された「フック」は、この問題を解決し、開発者が「ライフサイクル」ではなく「エフェクト（副作用）」という考え方をするよう促した。エフェクトとは、Reactのレンダリングプロセスとは別に発生する操作のことだ。これらは、Reactコンポーネントが外部のシステム（例えば、Webサーバーからのデータ取得、ブラウザのローカルストレージへのアクセス、タイマー処理など）と連携するための「逃げ道」として機能する。これらのエフェクトをコードで表現するのがuseEffectフックである。useEffectは、実行したいエフェクトの処理、エフェクトが不要になったときに実行するクリーンアップ処理、そしてエフェクトの再実行を判断するための依存配列という3つの要素を持つ。エフェクトを使う際の最も重要なルールは、「もし外部システムが関わっていないのであれば、通常エフェクトは必要ない」というものだ。

useEffectの理解がこれほど難しいのは、過去のドキュメントの記述が不明瞭であったことや、開発者が旧来のクラスコンポーネントのライフサイクルメソッドの考え方にとらわれすぎているためだ。多くの開発者は、「コンポーネントがマウントされたらコードを実行する」といったライフサイクル的な視点でuseEffectを使っていたが、これは本来の意図とは異なる。新しいReactドキュメントではuseEffectの正しい使い方について詳しく解説しているものの、その情報が十分に普及していなかったり、ドキュメントの目立ちにくい箇所にあったりしたため、多くの開発者に見過ごされてきた。

最も根本的な問題は、開発者がエフェクトを「コンポーネントの視点」で捉える傾向にあることだ。例えば、チャットルームに接続・切断するuseEffectのコードがあった場合、多くの人は「コンポーネントがマウントされたときと、roomIdが変わったときにチャットに接続し、コンポーネントがアンマウントされるときや、別のroomIdに接続する前に切断する」と解釈する。しかし、正しい「エフェクトの視点」では、「このコンポーネントはチャットルームに接続する責任がある。エフェクトがクリーンアップされるときには切断する。チャットルームの接続にはroomIdが必要なので、これを依存配列に含める」と考える。この考え方の違いが、useEffectの適切な使用につながる。

このような開発者の誤解が広まった結果、GitHub CopilotのようなAIツールもuseEffectを誤用したコードを生成することがあり、それがさらに誤った使用例を増やし、問題の解決を困難にしている。

では、useEffectはどのような場合に使うべきなのだろうか。具体的な例としては以下のケースが挙げられる。 一つ目は、外部APIからのデータ取得だ。例えば、Webサーバーからユーザー情報を取得する際にuseEffectを使用する。ただし、エラーハンドリングや、コンポーネントが画面から消えたときに通信をキャンセルする処理なども考慮する必要がある。 二つ目は、ローカルストレージなどのブラウザAPIとコンポーネントの状態を同期させる場合だ。ユーザーが選択したテーマカラーをlocalStorageに保存し、次回訪問時にその設定を復元するようなケースが該当する。 三つ目は、DOMイベントのリッスンだ。スクロールイベントなど、ブラウザの特定のイベントを監視し、それに応じてコンポーネントの状態を更新する際に使う。イベントリスナーは、useEffectのクリーンアップ関数で必ず削除する必要がある。

一方で、useEffectを使ってはいけない、あるいはより良い代替手段が存在する不適切な使用例も多い。 一つ目は、レンダリングのためにデータを変換するケースだ。例えば、姓と名という二つの状態から、useEffectを使ってフルネームという別の状態を生成する場合。これはuseEffectを使うべきではなく、レンダリング時に姓と名を結合して直接フルネームを計算すべきだ。 二つ目は、コストの高い計算結果をキャッシュする場合だ。フィルターされたリストのように計算に時間のかかる結果をuseEffectを使って状態に保存する代わりに、useMemoフックを使って計算結果を記憶させ、必要なときにだけ再計算させるのが適切だ。 三つ目は、プロパティ変更時にコンポーネントの状態をリセットする場合だ。親コンポーネントから新しいデータ（todos）が渡されたときに、子コンポーネントの検索キーワードをuseEffectでリセットするのではなく、keyプロップを使ってコンポーネント自体を再マウントさせる方法が一般的だ。もしkeyが使えない場合は、レンダリング中にプロパティの変更を検知して状態を直接更新することも可能である。 四つ目は、ユーザーイベントの処理をエフェクトで行う場合だ。チェックボックスの選択など、ユーザーの操作に応じて発生する処理は、useEffectではなく、そのイベントを処理するイベントハンドラー内で直接記述すべきだ。これにより、コードの流れが分かりやすくなる。 五つ目は、親と子コンポーネント間で状態を同期させる場合だ。子コンポーネントが独自の選択状態を持ち、useEffectでその状態を親コンポーネントに伝えるようなケースは避けるべきだ。代わりに、状態は親コンポーネントで管理し、その状態と、子コンポーネントが状態を変更するための関数をプロパティとして渡すことで、「単一の真実の源」を保つことができる。

外部システムとの同期という特定のシナリオでは、useSyncExternalStoreという新しいフックがuseEffectの代替手段として推奨されている。例えば、オンラインステータスを監視するカスタムフックをuseStateとuseEffectで実装していた場合、useSyncExternalStoreを使うことで、よりシンプルかつ効率的に記述できる。このフックは、外部ストアの変更を購読する関数と、現在の状態を取得する関数を受け取ることで機能する。

useEffectの将来に関して、ReactチームはReactコンパイラの導入を検討している。これは、開発者が手動でuseEffectの依存配列を指定する代わりに、コンパイラが自動的に必要な依存関係を検出してくれるというものだ。これにより、開発者は依存配列の管理に気を取られず、useEffectの内部で何が「副作用」として発生しているのかという本質に、より集中できるようになるだろう。

不必要なエフェクトをコードから排除することは、コードをよりシンプルにし、デバッグを容易にし、実行速度を向上させ、そしてエラーのリスクを減らすことにつながる。useEffectを正しく理解し、適切に使用することで、私たちはより高品質なコードを書くことができ、ひいてはAIが生成するコードの品質向上にも貢献するだろう。