MVVM Data-Binding Glitch: Diamond Dependency Propagation

Model Value (Source)

Model state S 40

Propagation Strategy

Hop latency 260 ms

Live Readouts

View D evals / cycle

Glitches detected

View D value

170

Correct value

170

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 walks edges in arrival (breadth-first) order with no dependency check. D is re-evaluated the instant either parent updates — so it fires once using the new B with the stale C (a wrong, transient value = a glitch), then fires again once C also arrives. Every model change costs 2 evaluations and 1 glitch.
Topological sort computes an evaluation order where every node's dependencies are fully updated before the node itself runs (Kahn's algorithm on the dependency DAG). B and C both settle before D is touched once — 1 evaluation, 0 glitches, always the correct value.

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 — without it, a UI briefly renders an inconsistent intermediate state on every multi-input binding.

Model S ViewModel B / C View D Glitch pulse

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.