Re:Observable API Proposal
by noelwelsh on Friday July 28, 2023 @02:49PM
(#36911432)
Glitches are transient incorrect values due to delays in propagating values. Imagine a diamond pattern of reactive values like:
d should be 0, 2, 4, ... but if, say, b updates and d sees this update before c updates then you can get incorrect values in d.
[ Parent
| on HN ]
Quite interesting. How does one resolve this?
Naive me would have d observe a and recalculate its value by rexomputing b and c then.
Other naive but complexity indulging me would store a dependency graph and use this graph to determine when one should wait for a value to update.
Surely there must be an easier way?
If b, c, and d were lazily evaluated (pull-based) you would also avoid this issue,
The key is topological sorting of a dependency graph. This can be done implicitly by storing a reactive variable node’s depth once it is created, and just making sure that updates are enqueued in separate queues per depth.
I have a somewhat small implementation that transparently batches updates with queueMicrotask in this library (bruh): https://github.com/Technical-Source/bruh/blob/a829af9df9405b...
They used to track a dependency map explicitly so they can determine when your “transaction” begins and ends so you can update all dirty at once.
Another way to deal with it is explicitly not dealing with it, eg. saying it is only (inconsistent) UI and will go away in a millisec…