MVVM Data-Binding Glitch: Diamond Dependency Propagation (2D)

Model Value (Source)

Model state S 40

Propagation Strategy

Hop latency 260 ms

Live Readouts

Sink evals this cycle

Glitches detected

Sink value

170

Correct value

170

Recomputes per Node (cumulative)

Node	Naive	Topo

Propagation Log

How it works

This models the "diamond dependency" in reactive data-binding (the mechanism behind MVVM's ViewModel → View binding): a Model value S feeds two independent derived properties, B = 2·S and C = S + 50, and a View binding D = B + C reads both. Algebraically D always equals 3·S + 50 once settled.

S changes
 ├─▶ B = 2·S   ─┐
 └─▶ C = S+50  ─┴─▶ D = B + C

Naive push is a synchronous depth-first cascade: the instant an edge arrives at a node, that node recomputes from whatever parent values it currently holds and immediately pushes to its own children. D fires once using the new B with the stale C (a wrong, transient value = a glitch), then fires again once C also arrives. Each diamond a value passes through doubles the sink's recompute count — measured live in the table on the left, not scripted.
Topological sort runs Kahn's algorithm on the affected subgraph first, tracking how many upstream (affected) parents each node is still waiting on. A node is only allowed to recompute once that count hits zero — i.e. after every upstream dependency has settled. B and C both settle before D is touched once — 1 evaluation, 0 glitches, always the correct final value.

"Extend graph" chains another diamond onto the current sink (it becomes the next diamond's source), so the naive-vs-topo gap compounds — this is exactly why production reactive frameworks (SwiftUI, Jetpack Compose, Vue's reactivity, MobX) schedule updates in topological / batched order instead of naively pushing on every parent write.

Source Derived Sink Glitch pulse