Reactのstrictとmodeの挙動！開発環境での警告を正しく理解

Reactを使っていると、開発時だけ見かける挙動――コンポーネントが二回描画されたり、Effectが二回走ることなど――に戸惑うことがあるはずです。特に「React strict mode 挙動」が気になる方は、この仕組みを正しく理解することで無駄な調査やバグを避けられます。この記事では、strict modeの目的、その具体的な動作、React 18で変わった点、トラブル回避の方法まで、開発者にとって必須の観点をわかりやすく解説します。

React strict mode 挙動とは何か？基本的な仕組みの理解

まず「React strict mode 挙動」の用語を分解すると、Reactで用いられるStrictModeコンポーネントが提供する、開発環境での特定の動作のことを指します。描画フェーズやEffect（副作用）のライフサイクルなどを特別に扱い、潜在的な不具合や将来の機能に対してコードを頑健にすることが主な目的です。

React strict mode 挙動は、実際には本番環境では発生せず、開発時のみ動作するチェックや追加処理を含みます。具体的には、関数コンポーネントの本体（レンダー中のロジック）やuseEffectやuseLayoutEffectのクリーンアップ処理が正しく記述されているかを確かめるため、コンポーネントをダブルレンダーしたり、初回マウント時にマウント → アンマウント → リマウントをシミュレートするなどの処理が実行されます。

StrictModeの目的と開発支援機能

StrictModeが提供する目的には主に次のようなものがあります。副作用がある処理がクリーンアップなしで残るのを防ぐこと、レンダー関数が純粋であることを確認すること、古いライフサイクルメソッドや非推奨APIの利用を警告することなどです。これによりバグを早期発見でき、将来のReactの更新や並列レンダリング（concurrent rendering）機能への対応が容易になります。

開発モードと本番モードでの違い

開発モード（development）ではStrictModeによる追加チェックが有効になっており、テストやログ取りなどで副作用や描画回数の増加が観察されます。これに対して本番モード（production）ではStrictModeによるこうしたチェックは無効であり、通常通り一回のレンダーやEffect実行になります。従って、「二回描画される」「Effectが重複する」という挙動は、本番ビルドでは起きないという点を理解しておくことが重要です。

React 18でのStrictMode挙動の変更点

React 18からはStrictModeの挙動に新しいチェックが追加されました。具体的には「初回のマウント時に、コンポーネントをマウント → アンマウント → リマウント」のサイクルをシミュレーションする機能です。これにより、useEffectやuseLayoutEffectなどのEffect系のフックに記述されたクリーンアップ処理の健全性がより厳しくチェックされます。これらの変更は開発モードに限られ、本番モードには影響しません。

React strict mode 挙動が具体的にどう現れるか：実例と挙動

React strict mode 挙動がどのような形でコードに影響を与えるかを具体的に見ていきます。実際のログの二重表示やEffectのクリーンアップの呼び出しなど、開発時に「なぜこうなるのか」を理解するための要素を整理します。

関数コンポーネント本体の二重呼び出し

StrictMode下ではレンダー関数に含まれる処理が二回呼び出されます。レンダーする際に副作用のある処理（プロップで受け取った配列を直接変更するなど）があると、二回目の呼び出しでその影響が顕在化しやすいため、純粋関数としての振る舞いが要求されます。またstate初期化関数やuseState、useReducerに渡す関数も同様に二重実行されることがあります。

useEffect / useLayoutEffectなどの副作用フックのマウント‐アンマウント‐リマウントのシミュレーション

React 18のstrict modeでは、コンポーネントを初めてマウントする際に、Effectをセットアップ後すぐにクリーンアップを行い、その後再度Effectをセットアップし直す挙動があります。これにより、Effect内でのcleanup処理が正しく書かれていないとメモリリークや重複処理などの問題が起きやすくなります。開発者はEffectの中でリスナ登録やタイマー、サブスクリプションなどがあれば必ずクリーンアップ関数を返すようにする必要があります。

参照コールバックやdeprecated APIの警告

StrictModeではrefコールバックのクリーニング（登録・解除）が正しく行われているか、非推奨となったライフサイクルメソッドやunsafe prefix付きのメソッドを使用していないかなどへの警告が発生します。これらは将来のバージョンでの互換性を保つ上で重要なチェックです。

React 18以前との違いを比較する

React strict mode 挙動はReact 18で拡張されており、以前のバージョンとの違いを明確に理解しておくことで、移行やデバッグがスムーズになります。ここでは何が変わったかを表で比較します。

このように、React 18からstrict modeのチェックが強化されており、より慎重な設計が必要になっています。

strict modeの動作でよくある勘違いと落とし穴

React strict mode 挙動を理解していても、「これはバグではないか」と感じる場面がいくつかあります。ここでは代表的な誤解とその正しい理解を紹介します。

consoleログが二回出るのはバグか？

コンポーネントのレンダー関数やuseEffectに含まれるconsole.logが二回出力される場面があります。これはstrict modeにおけるレンダー二回呼び出しやEffectのマウント‐アンマウント‐リマウントシミュレーションによるもので、本番では一回のみ実行されます。バグではなく意図された動作です。

非同期処理やAPI呼び出しが二回発火する問題

Effect内でAPIを呼び出す、タイマーを使う、サブスクリプションを登録するといった副作用がcleanupなしに記述されていると、重複実行の際に問題が起きやすいです。strict modeはこれを検出するため、cleanup関数の記述を強く推奨します。特に非同期処理ではキャンセル機構を備えるか、依存関係を明確にすることが大切です。

useMemo内で生成した値とEffectのcleanupの関係性

useMemoで生成したオブジェクトやクラスインスタンスをEffectの外で作成し、Effect内でcleanupするパターンは注意が必要です。strict modeではuseMemoの生成時が二重実行されてもcleanup時のコンテキストが合わなくなることがあります。生成とcleanupをEffect内に統合したり、依存関係を正しく管理することで問題を防げます。

開発においてstrict mode 挙動を正しく扱うコツとベストプラクティス

React strict mode 挙動を理解していても、実装で混乱することがあります。ここでは日常の開発で役立つ対策とベストプラクティスを紹介します。コードの健全性を保ちつつ、strict modeによる警告を活かす方法です。

副作用とcleanupの対応を徹底する

useEffectやuseLayoutEffectなどで副作用を持つ処理を実装する場合、必ずクリーンアップ関数を返すようにすることが基本です。例えばタイマーを設定したらclearTimeout／clearIntervalを、サブスクリプションを登録したら解除を、イベントリスナを追加したら削除を行うなどです。これにより、strict modeで再マウントがシミュレーションされたときにリソースの重複やメモリリークを防げます。

レンダラー本体での副作用を避ける

レンダリング関数内（component本体）では、プロップの配列を直接変更したり、外部変数をミューテートするなどの副作用を持つ処理を避けます。代わりにプロップのコピーを作る、immutableなデータ構造を使う、純粋関数の定義を意識することが望まれます。

開発モード専用の挙動を把握しデバッグに活かす

strict modeの挙動は開発モードのみで発生するため、production buildで再現しない問題はまずdevelopment buildで確認します。環境変数を使ってNODE_ENVがdevelopmentかどうか判定するなどで、conditionalロジックを入れることもできます。ログを整理し、どのレンダーやEffectが何回呼び出されたかを追うことで原因が見つかりやすくなります。

React strict mode 挙動が与える影響とその対策のまとめ

React strict mode 挙動は開発時にのみ現れる仕様であり、本番環境には影響しません。しかし開発者にとっては「見た目の不自然さ」や「二重処理」によって混乱を招くことがあります。これを理解し、以下の対策を実践することでコード品質を保てます。

パフォーマンスへの影響を最小限にする工夫

strict modeではレンダー関数やEffectが複数回呼び出されるため、重い処理をレンダー内に置かないようにしましょう。useMemoやuseCallbackで不要な再計算を抑え、依存配列を正確に設定することが大切です。コンポーネントの数を分割し、deep treeでの再レンダーを減らす設計も有効です。

ライブラリとの互換性を考慮する

第三者製のライブラリを使っていて、その中で副作用を内部で扱っている場合、strict mode下で想定外のクリーンアップ・再マウントが起きることがあります。そうしたライブラリの使用をレビューし、一部の処理を制御するか、strict modeの範囲を限定することが有効です。

バグ報告やデバッグ方針の整備

React strict mode 挙動に起因するトラブルは、ログの二重出力やEffectの重複発火などが典型例です。これらはバグではなく仕様なので、チーム内で共通理解を持つことが大切です。issueを整理して、strict modeあり／なしでの差異を記録し、解決すべき誤り（クリーンアップ不足など）を優先して直します。

まとめ

React strict mode 挙動は、開発環境で使われる重要なチェック機構であり、レンダーの二重呼び出しやEffectのマウント‐アンマウント‐リマウントのシミュレーションなどにより、コードを頑丈にするためのものです。React 18でこの挙動が強化され、開発者にとっての重要性が増しています。

本番環境には影響しないため、ログが二回出る等の現象は仕様と理解し、副作用のクリーンアップ、レンダラ本体での純粋な処理、ライブラリとの整合性などをチェックすることで、不要な混乱やバグを防げます。strict modeを活かし、より堅牢で将来も安心できるReactアプリケーションを構築していきましょう。