Expand description
Reactive wake: schedule a follow-up tick whenever the current tick wrote typed properties that downstream consumers haven’t observed yet.
§Why this exists - “the dialog is slow”
The app only ticks on wakes (input events, or the window backend’s
work_pending re-arm). Several state chains need one more tick
after the tick that writes a PropertyStore cell before their
effect is visible:
- a click handler writes
dialog_open->reconcile_if_blocksmounts / despawns the<dialog>body on the next tick, push_slider_to_signalmirrors a drag into its signal -> bound labels pull it on the next tick,- a derivation writes a derived cell that another consumer reads.
Without this system, that “next tick” never gets scheduled: the
window backend re-arms only when AnimationsActive or
FrameDirty says so, and a bare property write raises neither. The
transition then sat parked until an unrelated wake - measured live
on widget-garden: ~550 ms to open the dialog, ~4 s to close it
(whenever the next incidental event happened to arrive).
The fix: at the end of every tick (A11ySync, before
clear_property_store_dirty wipes the per-tick queue), raise
AnimationsActive when the dirty queue is non-empty. The window
backend’s work_pending check then re-arms a redraw, the follow-up
tick runs within a frame, and the consumers converge. Quiescence is
preserved: semantically-equal writes never enter the dirty queue,
so a settled UI stops requesting ticks the moment no cell actually
changes.
Functions§
- request_
tick_ on_ property_ writes - Raise
AnimationsActivewhen this tick ends with undrained property writes, so the write’s downstream consumers (if/for reconcilers, binding pulls, derivations-of-derivations) get their follow-up tick within one frame instead of waiting for the next unrelated input event.