おい、そこの君。Reactの深い森で、`useEffect`という名の懐深く、しかし時に気まぐれな獣と格闘している諸君に、今日は一つ、とっておきの話をしよう。我々が日々叩き込んでいるコードの裏側で、Reactが一体何を考え、どう動いているのか、その真髄に触れる話だ。特に、外部ストアの購読という、一見単純そうでいて、実はReactの核心的なレンダリングメカニズムと密接に絡み合うテーマについて、`useEffect`が持つ限界と、それを乗り越えるために生まれた`useSyncExternalStore`という強力なフックの必然性を、アーキテクトの視点から深く掘り下げていきたい。

`useEffect`による外部ストア購読の「泥沼」

我々は皆、外部ストア（例えば、独自のイベントバス、Redux以外の状態管理ライブラリ、Web Componentsの内部状態、ブラウザAPIなど）をReactコンポーネントで購読する際に、一度は`useEffect`の扉を叩いたことがあるだろう。そして、多くの場合はそれなりに動く。しかし、それはあくまで「それなり」だ。深淵を覗き込めば、そこにはレンダリングの整合性という、ゾッとするような問題が潜んでいる。

1. レンダリングの「引き裂かれた状態」（Teared State）

`useEffect`は、ご存知の通り、コンポーネントのレンダリングが完了し、DOMが更新された後に非同期に実行される。この「後」というタイミングが、外部ストアの購読においては致命的な問題を引き起こす可能性がある。

想像してみてほしい。

1. コンポーネントがレンダリングを開始し、外部ストアから`stateA`という値を取得して描画しようとする。
2. そのレンダリング処理が進行中に、別の非同期処理やイベントによって外部ストアの値が`stateB`に更新される。
3. コンポーネントのレンダリングが完了し、`useEffect`が実行される。ここで外部ストアの購読を開始し、現在の値`stateB`を取得して、コンポーネントの内部状態を更新する。

このシナリオでは、最初のレンダリングでは`stateA`に基づいて描画され、`useEffect`によって購読が開始された後、すぐに`stateB`で再レンダリングされる。この一瞬の間に、ユーザーは古い`stateA`に基づいて描画されたUIを目にすることになる。さらに悪いことに、同じ親コンポーネント配下の複数の子コンポーネントがそれぞれ`useEffect`で異なるタイミングで外部ストアを購読した場合、コンポーネントツリー内で異なる時点の状態が混在して描画されるという、まさに「引き裂かれた状態（Teared State）」が発生するのだ。

これはReactの設計思想、すなわち「状態が変化すれば、UI全体が一貫した状態で再レンダリングされるべきだ」という原則に真っ向から反する。特にReactのConcurrent Modeでは、レンダリング処理が中断・再開される可能性があるため、このTeared Stateのリスクはさらに高まる。Reactは、描画しようとしている内容が、コンポーネントツリー全体で一貫した状態を反映していることを保証したいのだ。

2. 競合状態（Race Condition）とメモリリークの温床

`useEffect`内での購読とクリーンアップは、常にペアで動く。しかし、コンポーネントのライフサイクルと外部ストアの更新が複雑に絡み合うと、競合状態が発生しやすくなる。

例えば、コンポーネントがアンマウントされる直前にストアが更新され、その更新が購読解除処理よりも早くキューに入ってしまった場合、アンマウントされたコンポーネントに対して不必要な状態更新がトリガーされ、メモリリークや未定義の動作につながる可能性がある。クリーンアップ関数は非同期に実行されることが多く、その間にストアの状態がさらに変化する可能性も考慮しなければならない。

3. 余計な再レンダリングと依存配列の悪夢

`useEffect`で外部ストアを購読する場合、通常はストアから取得した値を`useState`でコンポーネントの内部状態に保持する。ストアが更新されるたびに`setState`が呼ばれ、コンポーネントが再レンダリングされる。これは一見正しい動作に見えるが、Reactのスケジューリングの観点からは無駄が生じやすい。

また、`useEffect`の依存配列の管理も頭痛の種だ。もし購読関数自体がクロージャ内で定義され、外部スコープの変数に依存していた場合、その変数が変更されるたびに購読が解除され、再購読される。これはパフォーマンスのオーバーヘッドだけでなく、購読のライフサイクル管理を非常に複雑にする。

`useSyncExternalStore`の登場：整合性の守護者

これらの`useEffect`が抱える根本的な問題を解決するために、React 18から導入されたのが`useSyncExternalStore`だ。これは、まさに「外部ストアとReactのレンダリングパイプラインを同期させる」ために設計された、非常に強力なフックである。

`useSyncExternalStore`が提供する解決策

`useSyncExternalStore`は、以下の3つの関数を引数として受け取る。

1. `subscribe`: 外部ストアの変更を購読するための関数。この関数は、ストアが変更されたときにReactに再レンダリングを促すコールバック（Reactが内部的に提供する）を登録し、購読解除するための関数を返すべきだ。
2. `getSnapshot`: 外部ストアから現在のスナップショット（状態）を取得するための関数。この関数はレンダリング中に呼び出され、常に一貫した値を返さなければならない。
3. `getServerSnapshot` (オプション): SSR環境でハイドレーション時に使用される初期スナップショットを取得するための関数。これにより、サーバーとクライアントでの初期描画の不整合を防ぐ。

このフックの肝は、`getSnapshot`がレンダリング中に同期的に呼び出される点にある。Reactはコンポーネントをレンダリングする際、`useSyncExternalStore`が提供する`getSnapshot`を通じて、外部ストアの最新かつ一貫したスナップショットを取得する。これにより、コンポーネントが描画しようとするデータが、常にレンダリング開始時点での外部ストアの最新状態と一致することが保証されるのだ。

もしレンダリング中に`getSnapshot`が返す値が前回の呼び出しから変更されていた場合、Reactは現在のレンダリングを破棄し、新しいスナップショットに基づいて最初から再レンダリングを試みる。これは、Teared Stateを防ぎ、常に一貫したUIをユーザーに提供するための、Reactの強固なコミットメントだ。

また、`subscribe`関数によって登録されたコールバックは、ストアが更新された際にReactのスケジューラに直接通知する。これにより、`useEffect`のように一度DOM更新を待つ必要がなく、より効率的かつタイムリーに再レンダリングをスケジュールできる。メモリリークのリスクも、Reactが購読と購読解除のライフサイクルをより厳密に管理することで軽減される。

具体的なアーキテクチャへの示唆

`useSyncExternalStore`は、単なる便利なフックではない。これはReactのConcurrent Modeと密接に連携し、非同期で中断可能なレンダリング環境においても、外部ストアとの整合性を保証するための基盤を提供する。

• 堅牢性: Teared Stateのようなバグは、再現が難しくデバッグに時間がかかる。`useSyncExternalStore`を使用することで、このようなクラスのバグを根本的に排除できる。
• パフォーマンス: 不要な再レンダリングを削減し、Reactのスケジューラと協調することで、より効率的なUIの更新が可能になる。
• シンプルさ: `useEffect`で購読解除のロジックや依存配列の管理に頭を悩ませる必要がなくなる。`useSyncExternalStore`がそれらの複雑さを抽象化してくれる。
• 将来性: Reactの進化、特にConcurrent Modeが標準となる未来において、このフックは外部ストアとの連携において最も推奨されるアプローチとなるだろう。

コードで見る`useEffect`と`useSyncExternalStore`の比較

それでは、具体的なコード例を見て、その違いを肌で感じてみよう。簡単な数値カウンターを持つ外部ストアを想定する。

外部ストアの定義

// store.ts
type Listener = () => void;

class ExternalCounterStore {
private count = 0;
private listeners: Set = new Set();

// 現在のカウント値を取得する
getCount(): number {
return this.count;
}

// カウントを増やす
increment() {
this.count++;
this.emitChange(); // 変更をリスナーに通知
}

// カウントを減らす
decrement() {
this.count–;
this.emitChange(); // 変更をリスナーに通知
}

// リスナーを登録する
subscribe(listener: Listener): () => void {
this.listeners.add(listener);
// 購読解除関数を返す
return () => this.listeners.delete(listener);
}

// 全てのリスナーに変更を通知する
private emitChange() {
this.listeners.forEach((listener) => listener());
}
}

// シングルトンとしてエクスポート
export const counterStore = new ExternalCounterStore();

`useEffect`で外部ストアを購読する（非推奨の例）

この例では、`useEffect`を使ってストアを購読している。一見問題なさそうに見えるが、Teared Stateのリスクを内包している。

// UseEffectCounter.tsx
import React, { useState, useEffect } from ‘react’;
import { counterStore } from ‘./store’;

function UseEffectCounter() {
// 外部ストアから取得した値を保持するための内部状態
const [count, setCount] = useState(counterStore.getCount());

useEffect(() => {
// 購読時に現在のスナップショットを取得し、状態を更新
// ここがレンダリング後に実行されるため、レンダリング時に取得した値とズレる可能性がある
setCount(counterStore.getCount());

// ストアの変更を購読する関数
const handleChange = () => {
// ストアが更新されたら、内部状態も更新して再レンダリングをトリガー
setCount(counterStore.getCount());
};

// リスナーを登録
const unsubscribe = counterStore.subscribe(handleChange);

// クリーンアップ関数：コンポーネントがアンマウントされたり、依存配列が変わったら購読を解除
return () => {
unsubscribe();
};
}, []); // 空の依存配列でマウント・アンマウント時のみ実行

// 外部ストアを直接操作するボタン
const handleIncrement = () => {
counterStore.increment();
};

const handleDecrement = () => {
counterStore.decrement();
};

return (

);
}

export default UseEffectCounter;

`useSyncExternalStore`で外部ストアを購読する（推奨の例）

こちらが推奨されるアプローチだ。カスタムフックとして抽象化することで、よりクリーンに利用できる。

// useCounterStore.ts
import { useSyncExternalStore } from ‘react’;
import { counterStore } from ‘./store’;

// useSyncExternalStore を使ったカスタムフック
export function useCounterStore() {
// subscribe 関数：ストアの変更を購読し、リスナーを登録・解除する
const subscribe = (onStoreChange: () => void) => {
return counterStore.subscribe(onStoreChange);
};

// getSnapshot 関数：ストアから現在のスナップショット（値）を取得する
// この関数はレンダリング中に呼び出されるため、常に一貫した値を返す必要がある
const getSnapshot = () => {
return counterStore.getCount();
};

// getServerSnapshot 関数：SSR環境で初期値を取得するために使用（今回はクライアントサイドのみなので、getSnapshotと同じ値を返す）
// サーバーサイドレンダリング時にハイドレーションの不整合を防ぐ
const getServerSnapshot = () => {
return counterStore.getCount();
};

// useSyncExternalStore フックを利用して、外部ストアの値を取得
const count = useSyncExternalStore(subscribe, getSnapshot, getServerSnapshot);

return count;
}

// UseSyncExternalStoreCounter.tsx
import React from ‘react’;
import { counterStore } from ‘./store’;
import { useCounterStore } from ‘./useCounterStore’;

function UseSyncExternalStoreCounter() {
// カスタムフックを使って外部ストアのカウント値を取得
const count = useCounterStore();

// 外部ストアを直接操作するボタン
const handleIncrement = () => {
counterStore.increment();
};

const handleDecrement = () => {
counterStore.decrement();
};

return (

);
}

export default UseSyncExternalStoreCounter;

これらのコンポーネントを組み合わせて、App.tsxで表示してみよう。

// App.tsx
import React from ‘react’;
import UseEffectCounter from ‘./UseEffectCounter’;
import UseSyncExternalStoreCounter from ‘./UseSyncExternalStoreCounter’;

function App() {
return (

);
}

export default App;

このコードを実行し、開発者ツールでコンポーネントのレンダリングを監視したり、意図的にストアの更新タイミングをずらしたりすると、`useEffect`版で一瞬だけ古い値が表示される可能性があるのに対し、`useSyncExternalStore`版では常に一貫した値が描画されることが確認できるだろう。

結論：アーキテクトが選ぶべき道

`useEffect`は、Reactコンポーネントと外部システムとの間で副作用を同期させるための強力なツールだ。しかし、その非同期性ゆえに、外部ストアの購読のようにレンダリングとの厳密な同期が求められるシナリオにおいては、根本的な限界を抱えている。

我々が目指すべきは、単に動くアプリケーションではない。予測可能で、堅牢で、高性能なシステムだ。そのためには、Reactの内部メカニズムを深く理解し、それぞれのフックがどのような目的で設計され、どのような制約を持つのかを知る必要がある。

`useSyncExternalStore`は、外部ストアとの整合性を保証し、Concurrent Modeの恩恵を最大限に引き出すための、まさに「未来のReact」を実装するためのフックだ。既存のレガシーな`useEffect`ベースの購読ロジックをこれに置き換えていくことで、我々のアプリケーションは、より強固な基盤の上に立ち、ユーザーに一貫した、信頼できる体験を提供できるようになるだろう。

この知識を武器に、君のReactアプリケーションを次のレベルへと押し上げてほしい。それでは、また深淵で会おう。