【ITニュース解説】useSyncExternalStore: test snapshot identity and the initial SSR value

useSyncExternalStoreというReactの新しいフックは、Reactコンポーネントが、Reactの管理外に存在する「外部ストア」の状態を安全かつ効率的に利用するための機能を提供する。外部ストアとは、Reactのコンポーネントの状態とは独立してデータを管理する仕組みで、例えばReduxのようなグローバルな状態管理ライブラリや、ブラウザのストレージAPIなどがこれに該当する。このフックの主要な目的は、Reactのレンダリングプロセスと外部ストアの状態更新との間に生じる可能性のある「ティアリング」という不整合を防ぎ、外部ストアの状態変更をReactコンポーネントに確実に反映させることにある。ティアリングとは、Reactが画面を描画しようとしている最中に外部ストアの状態が変更され、その結果、コンポーネントが古いデータと新しいデータが混じった矛盾した画面を表示してしまう現象を指す。

このフックを効果的に利用するには、外部ストアが二つの重要な関数を提供する必要がある。一つはsubscribe関数で、これは外部ストアの状態が変更された際に通知を受け取るための「リスナー」と呼ばれる関数を登録し、さらにその登録したリスナーを解除するための関数を返す。もう一つはgetSnapshot関数で、これはストアの現在の状態を表す「スナップショット」を返す役割を担う。useSyncExternalStoreはこれらの関数を通じて外部ストアの状態を監視し、変更があればReactコンポーネントを再レンダリングする仕組みになっている。

今回の検証では、特にgetSnapshot関数が返すスナップショットの「同一性」が、useSyncExternalStoreの挙動にどのように影響するかを詳しく調査した。検証では、ストアの状態を変更する二つの異なる方法が試された。一つはreplaceというメソッドで、これはストアの状態が変更されるたびに新しいオブジェクトを作成し、その中に新しい状態を格納してリスナーに通知する。もう一つはmutateというメソッドで、これは既存のオブジェクトのプロパティを直接変更するだけで、新しいオブジェクトは作成せずにリスナーに通知する。どちらのメソッドもリスナーへの通知自体は行うが、useSyncExternalStoreを介したReactコンポーネントの挙動には大きな違いが見られた。

具体的には、mutateメソッドを使ってストアの状態を変更し、リスナーに通知した場合、画面に表示される値は更新されなかった。これは、getSnapshot関数が常に同じオブジェクトの「参照」を返していたためである。Reactは、getSnapshotが返すスナップショットが前のスナップショットとObject.isという厳密な比較方法で「同じオブジェクトである」と判断した場合、内部のデータが変更されていても、状態が変更されていないとみなし、コンポーネントの再レンダリングを行わない。つまり、オブジェクトの内容が変わっても、それが同じメモリ上の場所を指している限り、Reactは変化を検知しないのである。

これに対し、replaceメソッドを使ってストアの状態を変更した場合は、画面が期待通りに更新された。これは、replaceメソッドが状態を変更するたびに新しいオブジェクトを生成するため、getSnapshot関数も常に新しいオブジェクトの参照を返していたからである。Reactは、新しいオブジェクト参照が返されたことを検知すると、状態が変更されたと判断し、コンポーネントを再レンダリングする。この結果から、useSyncExternalStoreを利用する上での「契約」として、外部ストアは「データが変更されていない間はgetSnapshotが常に同じスナップショット（同じオブジェクト参照）を返す」ことと、「データが変更された場合には新しい不変のスナップショット（新しいオブジェクト参照）を返す」ことを守る必要があることが明確になった。この契約を守らないと、状態の変更が画面に反映されなかったり、逆に不必要な再レンダリングが頻繁に発生してアプリケーションのパフォーマンスを低下させたりする可能性がある。例えば、常に新しいオブジェクトを返してしまうと、Reactが無限に更新を検知し続けることになり、「更新ループ」という問題を引き起こす恐れもある。

また、subscribe関数がリスナーを登録するだけでなく、そのリスナーをストアから削除するための関数を返すという契約も非常に重要である。これは、Reactコンポーネントが画面から削除（アンマウント）された際に、そのコンポーネントが登録していた不要なリスナーを確実に削除し、メモリリーク（アプリケーションが使用し終わったメモリが解放されずに残ってしまう問題）を防ぐために不可欠な機能である。検証では、コンポーネントのマウント後にはリスナーが一つ登録され、アンマウント後にはゼロに戻ることが確認された。

サーバーサイドレンダリング（SSR）におけるuseSyncExternalStoreの振る舞いも検証された。SSRでは、ウェブページをサーバーで事前にHTMLとして生成し、その後クライアント側のブラウザでそのHTMLにJavaScriptの機能やイベントハンドラを付与してインタラクティブにする「ハイドレーション」というプロセスが行われる。この際、サーバーでHTMLを生成するのに使われたストアの初期値と、クライアント側でハイドレーションを行う際にuseSyncExternalStoreが読み取る初期値が一致している必要がある。検証では、サーバーでcountが0のHTMLを生成し、クライアント側のストアはcountが1で初期化されているケースと、クライアント側も0で初期化されているケースを比較した。

このサーバーとクライアント間の初期値の同期を適切に行うために、useSyncExternalStoreにはgetServerSnapshotという関数も渡すことができる。これは、クライアント側でハイドレーションを行う際に、サーバーでレンダリングされた時点のストアの状態を読み取るために使用される。検証結果から、getServerSnapshotを適切に設定し、サーバーの初期値とクライアントのハイドレーション時の初期値が一致するようにした場合、コンポーネントはまずサーバーでレンダリングされた値（0）を読み取り、その後にクライアントストアの最新の値（1）にスムーズに移行することが示された。これにより、ユーザーはサーバーから提供された内容をそのまま見ることができ、その後、JavaScriptが有効になった際に最新の状態が適用されるため、ユーザー体験が向上する。

しかし、getServerSnapshotを省略したり、サーバーとクライアントで初期値が一致しない場合、ハイドレーションの際に「ミスマッチ」が発生する可能性がある。これは、サーバーが生成したHTMLと、クライアント側で期待される初期状態が異なっていることを意味し、エラーを引き起こしたり、画面の一時的なちらつきなどの予期せぬ挙動につながることがある。最終的な画面表示だけを見るとどちらのケースも同じ値になっていたとしても、途中のミスマッチを見逃してしまうため、getServerSnapshotを正しく実装することが重要だと検証は示している。

useSyncExternalStoreは、外部ストアそのものの実装を代替するものではない点に注意が必要だ。このフックは、createCounterStoreのような外部ストアが持つsubscribeとgetSnapshotといったインターフェースを、Reactのレンダリングサイクルと安全に連携させるための「橋渡し役」である。これにより、開発者はReactの内部的な状態管理の複雑さに直接触れることなく、外部ストアをReactコンポーネントと効率的かつ堅牢に統合できる。

この検証は、React 19.3.0といった比較的新しい環境で実施され、useSyncExternalStoreの安定した動作が確認された。このフックを正しく理解し、スナップショットの同一性に関する契約やSSR時の初期値の扱いに注意を払うことで、システムエンジニアは外部ストアを活用した堅牢でパフォーマンスの高いWebアプリケーションを開発できるだろう。