SSRと`useEffect`：ハイドレーションの深淵で溺れないためのアーキテクチャ設計
React開発者がキャリアのどこかで必ず直面する壁、それが「サーバーとクライアントの不一致」です。特に、`useEffect`がSSR（サーバーサイドレンダリング）環境で一切実行されないという仕様は、多くのエンジニアを混乱の渦に巻き込みます。
しかし、これはバグではなくReactが堅牢なUIを構築するために定めた「境界線」です。この境界線を理解せずして、真にパフォーマンスと堅牢性を両立するWebアプリケーションは構築できません。今回は、SSR環境における`useEffect`の挙動を解剖し、現場レベルで発生する「ハイドレーション・ミスマッチ」をいかに未然に防ぐかについて、深く掘り下げていきます。
—
なぜSSRで`useEffect`は沈黙するのか
結論から言えば、ReactのSSRは「静的なマークアップの生成」に特化しているからです。`useEffect`はコンポーネントがDOMにコミットされた後に発火する副作用であり、サーバー側にはDOMという概念そのものが存在しません（サーバーが生成するのはあくまで文字列としてのHTMLです）。
サーバー側で`useEffect`を実行してしまうと、副作用（APIコールや購読）がリクエストごとに二重発生し、メモリリークや意図しない外部連携を誘発します。Reactはこれを未然に防ぐため、SSR環境下では`useEffect`を完全に無視し、レンダリング関数内のロジックのみを同期的に実行します。
ハイドレーション後の「一瞬の空白」を制御する
`useEffect`はクライアントサイドでのハイドレーションが完了し、ブラウザがDOMを認識した直後に初めて実行されます。ここで我々が注意すべきは、「サーバーが描画したHTML」と「クライアントが最初に生成するDOM」の間に存在するラグです。
例えば、`localStorage`の値や`window.innerWidth`に依存したUIをSSRしようとすると、サーバー側ではそれらにアクセスできないため、初期値とブラウザ側の値が乖離し、ハイドレーション・エラーが発生します。
推奨される回避策：二段階レンダリングパターン
コンポーネントの初期状態をクライアントサイドのみで確定させることで、ハイドレーション・ミスマッチを回避します。
import { useState, useEffect } from ‘react’;
const ClientOnlyComponent = () => {
// 初期状態をnullにしておくことで、SSR時とクライアント側の初回レンダリングを一致させる
const [isClient, setIsClient] = useState(false);
useEffect(() => {
// コンポーネントがマウントされた後、初めてクライアント側であることを確定する
setIsClient(true);
}, []);
// SSR時は何もレンダリングせず、クライアント側でハイドレーションが終わった後にのみ表示
// これにより、ハイドレーション・ミスマッチを完全に封じ込める
if (!isClient) {
return
;
}
return
;
};
—
パフォーマンスを殺さない副作用の設計
`useEffect`は万能ですが、依存配列（dependency array）の管理を誤ると、再レンダリングの嵐を招き、ブラウザのメインスレッドを占有します。特にSSR経由でデータを受け取る際、副作用がハイドレーションの完了を待たずに暴走するような設計は避けるべきです。
1. 非同期処理の競合回避（Race Condition）
SSR環境から引き継いだ初期データを、`useEffect`内で更新しようとするケースは非常に危険です。クリーンアップ関数を徹底し、古いエフェクトが新しい状態を上書きしないよう設計しましょう。
useEffect(() => {
let active = true;
const fetchData = async () => {
const data = await api.fetch();
// クリーンアップ関数で制御することで、コンポーネント破棄後の状態更新を阻止
if (active) {
setData(data);
}
};
fetchData();
// クリーンアップ関数：コンポーネントがアンマウントされるか、
// 依存配列が変化した直前に実行される
return () => {
active = false;
};
}, [id]); // 依存配列は最小限に。無闇な追加は再実行のトリガーになる
2. メモリ効率とレンダリング負荷の最適化
SSR環境下では、不要な副作用を抑制するために、`useLayoutEffect`の使用には細心の注意が必要です。`useLayoutEffect`はブラウザの描画前に同期的に実行されるため、SSR環境で無理に使うと、クライアントサイドでの初回表示速度を著しく低下させます。基本は`useEffect`を優先し、レイアウト調整が必要な場合にのみ`useLayoutEffect`を検討してください。
—
チーフアーキテクトからの提言：SSRの先にあるもの
React 18以降のストリーミングSSRや、Server Components（RSC）の台頭により、`useEffect`に頼る場面は以前よりも減りつつあります。
- データ取得は可能な限りServer Componentsへ: クライアントサイドでの副作用を減らすことで、ハイドレーションのコストを大幅に削減できます。
- 「ハイドレーション・ミスマッチ」を恐れない: 適切なプレースホルダー戦略を立てることで、UIのちらつき（Layout Shift）を抑え、UXを最大化できます。
結局のところ、`useEffect`を使いこなすということは、「ReactがDOMをどう管理し、サーバーがどこまで責任を持ち、クライアントがいつバトンを受け取るか」というプロセスの全容を理解することに他なりません。
「とりあえず`useEffect`」という安易なコードに逃げず、その副作用が「いつ」「誰によって」実行されるのか。その問いを常に持ち続けてください。その執念こそが、技術負債のない、堅牢で美しいアプリケーションを構築する唯一の道です。
コメント