シグナルと細粒度リアクティビティ

何を解決する仕組みか

Reactのようなフレームワークは、状態が変わると コンポーネント関数を丸ごと再実行 し、その結果の仮想DOMを前回のものと比較（差分検出）して、変わった部分だけ実DOMに反映します。この方式は「状態→UI」を純粋関数として扱える利点がありますが、状態が1つの文字列を書き換えただけでも、そのコンポーネント配下の仮想DOMツリーを丸ごと作り直し、比較する処理が挟まります。

シグナル（Signal）ベースの細粒度リアクティビティは、この差分検出そのものを不要にする設計です。「どの値がどのDOM更新に使われているか」を実行時に自動で記録しておき、値が変わったら その値を直接使っている箇所だけ をピンポイントで更新します。コンポーネント関数は基本的に最初の1回しか実行されません。仮想DOMもツリー比較も存在しない。これがSolidJSやPreact Signals、Vueの内部（refとreactive）が採用するモデルです。仮想DOM側の差分アルゴリズムの詳細は SPA/SSR/SSGのレンダリング戦略 を、コンポーネント外の描画パイプラインは ブラウザのレンダリング を参照してください。

シグナルの内部構造：値・購読者・自動登録

シグナルは概念上、次の3つを持つオブジェクトです。

鍵になるのは、購読登録が 手動ではなく実行時の自動観測 で行われる点です。ランタイムはグローバルに「今どの計算（エフェクトやコンポーネント）が実行中か」を1つのスタック変数で追跡しています。この状態を仮に「現在実行中コンテキスト」と呼びます。

let currentComputation = null; // 実行中のエフェクト/派生値を指す

function createSignal(initial) {
  let value = initial;
  const subscribers = new Set();

  function read() {
    if (currentComputation) {
      subscribers.add(currentComputation); // 自動登録
    }
    return value;
  }

  function write(next) {
    if (next === value) return; // 値が変わらなければ何もしない
    value = next;
    for (const sub of [...subscribers]) sub.execute();
  }

  return [read, write];
}

readが呼ばれた瞬間、たまたま実行中だった計算（currentComputation）が「この値に依存している」と自己申告する形で購読者集合に加わります。開発者が依存配列を明示的に書く必要はありません。これがReactのuseEffect(fn, [a, b])のような 手動の依存配列 との決定的な違いです。手動配列は書き漏れると古い値を参照するバグ（stale closure）を生みますが、自動追跡は「実際に読んだものだけ」を正確に記録するため原理的にこの種の齟齬が起きません。

依存グラフと伝播：プッシュ型の再計算

これらのシグナル・エフェクト・派生値をノードとして繋ぐと、有向グラフができます。シグナルが書き換わると、そのノードから購読者へ、さらにその購読者の購読者へと グラフを辿ってプッシュ通知 されます。これがプッシュ型（push-based）リアクティビティです。

対してReactのフックモデルは基本的にプル型に近く、「状態が変わった」という通知を受けたコンポーネントが次のレンダーフェーズで 改めて自分の描画関数を呼んで結果を取りに行く 構造です。どちらも「変化の伝播」を扱う点は同じですが、単位が違います。

グリッチ回避：ダイヤモンド依存と実行順序

複数の計算が同じシグナルに依存し、さらにそれらの計算同士も依存関係を持つ場合（ダイヤモンド依存）、素朴なプッシュ通知は同じノードを複数回、しかも古い値のまま再計算してしまう危険があります。

      A（シグナル）
     /            \
    B（Aに依存）   C（Aに依存）
     \            /
      D（B と C の両方に依存）

Aが更新されると、素朴な実装ではB経由の通知でDが1回、C経由の通知でDがもう1回、計2回実行されがちです。しかも1回目の実行時点ではCがまだ古い値のままの可能性があり、Dが一瞬だけ不整合な値を見てしまう（グリッチ）ことになります。

これを避けるため、実用的な実装は次のいずれかの戦略を取ります。

• トポロジカル順序での実行: 依存グラフを事前に順序付けし、あるノードの全ての依存元が更新し終わってから、そのノードを実行する。
• バッチング（同期的な更新のまとめ処理）: 1つのイベントハンドラ内での複数のシグナル書き込みを即座に伝播させず、マイクロタスクや明示的な区切りまで溜めてから、影響を受けるノードを重複なく1回だけ再計算する。
• 世代カウンタ/バージョン管理: 各ノードに更新世代の番号を持たせ、同一世代内での再計算を1回に制限する。

実行時コストの違いが生む体感差

仮想DOM方式は更新のたびに「コンポーネント関数の再実行→仮想DOM生成→前回との比較→実DOM反映」という一連の処理を通ります。リスト内の1項目だけが変わっても、そのリストを描画するコンポーネント全体が再実行されるのが基本形で、これを避けるにはReact.memoやkeyの最適化を開発者が意識的に行う必要があります。

細粒度リアクティビティでは、コンポーネント関数自体は初期マウント時に1度しか実行されません。以降の更新は「シグナルの値を直接埋め込んだDOMノードのテキストや属性を書き換えるエフェクト」がピンポイントで走るだけで、コンポーネント関数の再実行もツリー比較も発生しません。更新コストが状態を使っている箇所の数に比例し、UIツリー全体の大きさには比例しないというのが、このモデルの中心的な利点です。もっとも、依存グラフの構築・維持自体にもコストがあり、シグナルが極端に細かく大量にあるアプリではグラフの管理オーバーヘッドが無視できなくなる点は留意が必要です。

まとめ