3 ms·

the ability to do efficient updates in large DOM.trees It was the ability to do efficient updates based on large VDOM diffs. The speed of updates is the same b

by wruza 3y ago

the ability to do efficient updates in large DOM.trees It was the ability to do efficient updates based on large VDOM diffs. The speed of updates is the same between a React VDOM-diff update plan and a direct update of the same size based on e.g. observers.

nine_k 3y ago
Yes, that's the point: computing what needs to change using observers quickly becomes hard. React allows you to run all updates against an unchanged view; observers can interact with each other's updates. While React proper may be too large, I find the approach indispensable for more complex interfaces. One can pick Preact instead. But it's indeed overkill for adding small bits of interactivity to large, mostly static documents.
- 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

Yes, that's the point: computing what needs to change using observers quickly becomes hard. React allows you to run all updates against an unchanged view; observers can interact with each other's updates. While React proper may be too large, I find the approach indispensable for more complex interfaces. One can pick Preact instead. But it's indeed overkill for adding small bits of interactivity to large, mostly static documents.

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.