インタラクティブデモ

ダイヤモンド依存関係のグリッチを実際に見る

2つの派生値が同じソースに依存している場合（ダイヤモンド依存関係）、一部のリアクティブライブラリは不整合な中間状態（グリッチ）を発行します。このデモでは、その違いを自分の目で確認できます。

仕組み

各キャンバスをクリックしてドラッグし、軌跡を描いてください。各ドットは、同じダイヤモンド依存関係グラフを使用するライブラリのリアクティブパイプラインによって配置されます：

mousePos (source: {x, y})
  ├── derivedX = map(pos => pos.x)
  ├── derivedY = map(pos => pos.y)
  └── combine([derivedX, derivedY])
        └── draw dot at {x, y} + check consistency

発行された各位置は最新のマウス位置と比較されます：

• 青いドット — 発行された (x, y) が実際のマウス位置と一致（整合）。
• 赤いドット — 一方の軸は更新されたがもう一方はまだ（グリッチ — ドットがドラッグパスから外れて表示される）。

注目ポイント

ライブラリ	グリッチ	理由
SynState	0	derivedX と derivedY がどちらも深さ順に再計算されてから、combine と subscriber が実行される
RxJS	多数	combineLatest は derivedX が変わった時点で、derivedY が前の位置のまま発行し、その後もう一度発行する
Jotai	0	購読している atom は読まれたときに、両方の入力の後で再計算される
MobX	0	reaction はマウス位置を書き換えたアクションの後、すべての入力が最新になってから computed 値を読む
Preact Signals	0	effect が computed 値を読み、各 computed はソースのどれかが新しいバージョンなら読まれた時点で再計算される
Solid	0	書き込みの下流のメモをすべて印付けし、メモを再実行してからエフェクトが実行されるので、両方の新しい値が見える

このダイヤモンドでは 6 つのうち 5 つがグリッチフリーです。5 つとも、派生値については保証があるからです。違いが出るのは、リクエストを開始するステップのように、値を書き込むエフェクトや reaction として書かれたステップです。その場合は Signals の上の operatorで扱っています。また RxJS の余分な発行はグラフが大きくなるほど増えます。次のデモでその回数を数えます。

グリッチが重要な理由

実際のアプリケーションでは、ダイヤモンド依存関係は、共有状態から算出されるスタイル、派生 UI 値、フォームバリデーションなど、あらゆる場面で現れます。そしてグリッチは以下を引き起こします：

• 視覚的なちらつき — UI がありえない中間状態をレンダリングする。
• 無駄な作業 — 余分な発行のたびに不要な副作用が実行される。combineLatest に $N$ 個の入力がある場合、ソース1回の更新で $N+1$ 回発行される — グラフが大きくなると $O(N^2)$ の急激な性能劣化を引き起こす（以下のデモで実演）。
• ロジックのバグ — 不整合なデータで副作用が実行される。

SynState を含むグリッチフリーのライブラリは、これらの問題をライブラリレベルで排除しているため、手動の回避策は不要です。

---

ディープ依存関係チェーン： 負荷時の伝搬

このデモは、6 つのライブラリそれぞれで同じリアクティブグラフを構築します： 各ノードが前のノードに依存する深さ $N$ のチェーンで、最終的な combine/derive がすべての $N+1$ 個の出力を読み取ります。

ヘビの尻尾がマウスを追従します — 各セグメントはチェーン内のステージで、線形補間（lerp）を使用して前のステージにスムーズに追従します。ヘビ全体を描画するために、すべての $N+1$ 個の出力（head + $N$ ステージ）が1つの combine に集約されます：

上図は $N = 3$ の場合です。デモではスライダーで $N$ を調整できます。チェーンの深さを増やして、Total updates カウンターを比べてください。

注目ポイント

• Total updates は各ライブラリの subscriber が呼ばれた回数です。6 つのうち 5 つは、$N$ にかかわらずマウス移動 1 回につき 1 回です。
• RxJS はマウス移動 1 回につき約 $N+1$ 回で、$N$ が大きくなるほどカウンターが引き離され、高い $N$ ではキャンバスがカクつきます。
• Avg μs/update は、subscriber の各呼び出しが蛇を描くのにかかる時間です。伝搬は含まないので、どのライブラリでもほぼ同じで、違いは呼び出しの回数に出ます。この形のチェーンを伝わる伝搬はベンチマークのディープチェーンシナリオで計測しています。

高い N で RxJS が急激に劣化する理由

Total updates カウンターを確認してください： RxJS は同じマウス移動に対して SynState の約 $N+1$ 倍多くの更新を示します。combineLatest は $N+1$ 個の入力のいずれかが値を発行するたびに実行されます。1回のマウス移動で、scan チェーンは順次伝搬します：

1. source が発行 → combineLatest が実行（source のみ更新、scan はまだ古い値）
2. scan₁ が発行 → combineLatest が再び実行
3. scan₂ が発行 → また実行
4. … すべての $N$ ステージについて

これらの $N+1$ 回の実行それぞれが $N+1$ 点のフルキャンバス再描画をトリガー → $O(N^2)$。これは最初のデモで示したグリッチ問題が性能面で顕在化したものです。

まとめ： 6ライブラリの比較

状態を持つ段の書き方はライブラリごとに異なり、2列目がこのデモでの書き方です。各ライブラリの一般的な伝搬の仕組みは評価モデルにあります。

ライブラリ	このデモでの段	マウスイベントごとの subscriber 呼び出し	イベントごとの総作業量
SynState	scan operator、ルートから深さ順にプッシュ	1（combine）	$O(N)$
RxJS	scan operator、購読ごとに深さ優先でプッシュ	$N+1$（combineLatest）	$O(N^2)$
Jotai	1つ前から導出する selectAtom の atom	1（store.sub）	$O(N)$
MobX	1つの reaction が1つの action で書き込む box	1（autorun）	$O(N)$
Preact Signals	1つの effect が1つの batch で書き込む signal	1（effect）	$O(N)$
Solid	前の値を受け取る memo、印付けの後に再実行	1（createEffect）	$O(N)$

RxJS 以外のライブラリはすべてマウスイベントごとに subscriber を1回だけ呼び出すので、作業量はどれも $N$ に比例します。その中で 1 回の更新にかかるコストは、ライブラリとグラフの形によって決まる定数です。次のデモでそれが見え、ベンチマークで計測しています。

---

スループット： 負荷時の更新ごとのオーバーヘッド

このデモでは、$O(N^2)$ の更新回数が支配的になる RxJS を除き、更新ごとに subscriber を 1 回だけ呼ぶ 5 つのライブラリを実行します。

仕組み

ボールが自動的に円軌道を周回します。各キャンバスは上記のスプリングデモと同じ深さ $M$ のリアクティブチェーンを実行します。違いは、マウスイベントごとに1回のソース更新ではなく、各アニメーションフレームで $K$ 回のソース更新が同期ループでチェーンを通じてプッシュされることです。

each animation frame:
  for k in 0..K-1:
    update source position (micro-step along orbit)
    → propagate through depth-M scan chain
    → subscriber records latest points
  draw snake once

これにより更新ごとのオーバーヘッドが $K$ 倍に増幅されます。更新毎の処理時間が 16ms を超えると、アニメーションはフレーム落ちしてカクつきます。

注目ポイント

• ms/frame は 1 フレームの $K$ 回の更新にかかった時間で、このブラウザとこの端末で計測した値です。60fps の 1 フレームの予算である 16ms を超えると赤に変わります。
• $K$ と $M$ をキャンバスがカクつくまで上げてみてください。どれが先に、どの $K$ でカクつくかはブラウザ、端末、ページの他の処理で変わるので、ここの数値はベンチマークではありません。同じグラフを条件をそろえて実行したものはベンチマークのディープチェーンシナリオにあります。
• 各ライブラリが更新ごとに何を、いつ行うかは評価モデルにあります。

次のステップ

• パフォーマンスベンチマーク — ここで示したシナリオの定量的な計測結果と、追加のグラフトポロジーの比較。
• SynState がグリッチを解決した方法 — 深さ順伝搬アルゴリズムの詳細。
• ライブラリ比較 — SynState と RxJS、Jotai、MobX 等の機能別比較。