2 ms·

observers can interact with each other's updates. They only do that if you build a dependency graph instead of a dependency tree and iff the observing framewor

by wruza 3y ago

observers can interact with each other's updates. They only do that if you build a dependency graph instead of a dependency tree and iff the observing framework allows that, and without any loop resolution method. The common technique for graphs under dumb observing is to create a single update routine and pass the name of an emitter to it. I’ve built literally hundreds of interfaces using this (most of them what they’d call “more complex”) and never met any issues React kids are taught to be scared of. UI dataflow was never even a serious concern to be worth a name. The whole premise of React compares it to a “generic detergent” which doesn’t really exist.

nine_k 3y ago
I agree that a tree would solve the problem. How do you efficiently compute such a tree, given an event like clicking a button, somewhere far from its potential root? I'm not an expert in frontend development, but all solutions I've seen either used a variant of virtual DOM, or two-way bindings (the latter a non-starter for me). What did I miss?
- wruza 3y ago
  You don't have to compute it, it is natural. Observers subscribe (this builds a tree), receive notifications and propagate changes via a set of [possibly common] routines that update other values. The difference is, React dataflow is "returns new state with old state and (returns new state with old state and (returns new state, which triggers the above internally), which triggers the above internally), which triggers the reconciliation". And the classic way is "triggers a state, which triggers a set of states, which triggers a set of states, and every triggered control flags a redraw internally with a proper granularity at gui side". or two-way bindings (the latter a non-starter for me). What did I miss? That they may be a starter, I guess. Or you can use "control X observes data A", "data B, C observe control X" dataflow. It doesn't really matter, because two-way bindings simply push input down to the data level instead of treating controls as explicit data storage. With two-way bindings you can erase the UI layer completely and still get a fully functioning object, which is useful for automation and for reusing/macroing of a proper functionality.

by wruza 3y ago

nine_k 3y ago

I agree that a tree would solve the problem. How do you efficiently compute such a tree, given an event like clicking a button, somewhere far from its potential root? I'm not an expert in frontend development, but all solutions I've seen either used a variant of virtual DOM, or two-way bindings (the latter a non-starter for me). What did I miss?

wruza 3y ago
You don't have to compute it, it is natural. Observers subscribe (this builds a tree), receive notifications and propagate changes via a set of [possibly common] routines that update other values. The difference is, React dataflow is "returns new state with old state and (returns new state with old state and (returns new state, which triggers the above internally), which triggers the above internally), which triggers the reconciliation". And the classic way is "triggers a state, which triggers a set of states, which triggers a set of states, and every triggered control flags a redraw internally with a proper granularity at gui side". or two-way bindings (the latter a non-starter for me). What did I miss? That they may be a starter, I guess. Or you can use "control X observes data A", "data B, C observe control X" dataflow. It doesn't really matter, because two-way bindings simply push input down to the data level instead of treating controls as explicit data storage. With two-way bindings you can erase the UI layer completely and still get a fully functioning object, which is useful for automation and for reusing/macroing of a proper functionality.