The funny thing is that, were it not for the deviation from the reference implementation, the glitch might not have been noticeable.

OMG. Hooks. use-effect, use-reducer, use-layout-effect... if I could understand any of that I bet the dataflow works by updating local storage, relying on some dispatch off that to get the to-do to disappear based on the localStorage incarnation of the to-do. The fix would be to make the maintenance of localStorage a pure side-effect of state changes to an in-memory to-do with reactive properties. Then the click to signify completion simply sets the to-do (reactive) property completed to true, and a watcher/observer sees the to-do has changed and re-writes the localstorage incarnation. In Matrix, we use the term "observer" correctly in the sense of a bystander, and we can specify side-effects by type of property owner. In rxTrak, a to-do is a drug r/x that needs to be filled. rx-upsert writes to localStorage: (defmethod observe-by-type [:rxtrak.rx/rx] [slot me new-val old-val c] (when-not (= old-val unbound) (rx-upsert me))) Translated, if any slot changes, upsert the whole to-do. (Observers are not called unless a property values changes.)