Ahhh, I love learning about graph algorithms. (A fun Discrete Math For Programmers class once suckered me into double-majoring in math, until I found myself in a mind-flaying hellscape of tensors and finite fields and had to retreat to CS.)
I am confused about the use of lazy algorithms here, because they don’t work when a dynamic value subscriber has side effects … and in an app the ultimate purpose of reactivity is to update things onscreen. If a reactive value is driving an HTML element, it has to be updated eagerly.
On the lazy algorithms, I think the integration with a UI library calls .set() (like in the lit integration) so the lazy graph gets driven in an eager context, but only the rendered parts of the state graph will be computed, and unused parts of the state graph remain lazily un-computed.
I have thought for some time that browser vendors should stop any work on “Web Components” and do useful stuff like add a native reactivity API instead to “pave the cowpaths”.
Ahhh, I love learning about graph algorithms. (A fun Discrete Math For Programmers class once suckered me into double-majoring in math, until I found myself in a mind-flaying hellscape of tensors and finite fields and had to retreat to CS.)
I am confused about the use of lazy algorithms here, because they don’t work when a dynamic value subscriber has side effects … and in an app the ultimate purpose of reactivity is to update things onscreen. If a reactive value is driving an HTML element, it has to be updated eagerly.
On the lazy algorithms, I think the integration with a UI library calls
.set()(like in the lit integration) so the lazy graph gets driven in an eager context, but only the rendered parts of the state graph will be computed, and unused parts of the state graph remain lazily un-computed.I have thought for some time that browser vendors should stop any work on “Web Components” and do useful stuff like add a native reactivity API instead to “pave the cowpaths”.