3 ms·
Quite interesting. How does one resolve this? Naive me would have d observe a and recalculate its value by recomputing b and c then. Other naive but complexi
by aatd86 3y ago
Quite interesting. How does one resolve this?
Naive me would have d observe a and recalculate its value by recomputing 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?
- mappu 3y agoIf b, c, and d were lazily evaluated (pull-based) you would also avoid this issue,
- wlib 3y agoThe 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/a829af9df9405b906aca07f2dce24f25568b9ff8/packages/bruh/src/reactive/index.mjs#L37 https://github.com/Technical-Source/bruh/blob/a829af9df9405b...
- pezo1919 3y agoThey 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…