I like it. Here is my own rendition of Dan's approach (interleaved with experience from about 12 K lines of React native/ react native web)
A ) Dependency Tree (eg dom or virtual dom) is the interface user interacts with.
B ) Each interactable element in the tree can have its own state.
C ) Each interactable element gets data or update data from/to its own state.
It can also get data from 'properties' that a parent passed on (but the interactable cannot update those properties itself, instead it must call its parent's function to do that)
D ) After the above A, B, C are setup -- the code interacts with the state, not with UI elements
E) The UI runtime is a collection of mechanism that supports A, B, C.
This includes :
1) Primitives allowing Interactable to be attached and interact with the dependency tree, ability to receive data from parents
2) Well defined (from both APIs, callbacks, and Data) primitives -- that enable state management within the Interactable, and across their dependency tree
This also includes mechanism deciding efficiently, which state changes affect which Interactable)
3) Developer friendly run time helpers to debug and manage the above
----
Cleary A) --> can be a dependency tree of Excel cells, or Matrices, or robot's extremities, for that matter.
Clearly B) (the state) is widely appreciated these day ViewModel (as it is called in Android's new JetPack LiveData components)
The state is also the thing that can be validated, even with TLA+ (which is what am thinking about, in a downtime).
And it is much much easier, in my view to map interaction business rules to state, rather than to UI.
---
I am looking forward to try this with my console UIs project.
---
I also have a strange feeling, that this model will work when I have to manage complex backend interdependencies,
where updates to distributed caches affect the algorithms running across a server farm.
A ) Dependency Tree (eg dom or virtual dom) is the interface user interacts with.
B ) Each interactable element in the tree can have its own state.
C ) Each interactable element gets data or update data from/to its own state.
It can also get data from 'properties' that a parent passed on (but the interactable cannot update those properties itself, instead it must call its parent's function to do that)
D ) After the above A, B, C are setup -- the code interacts with the state, not with UI elements
E) The UI runtime is a collection of mechanism that supports A, B, C.
This includes :
1) Primitives allowing Interactable to be attached and interact with the dependency tree, ability to receive data from parents
2) Well defined (from both APIs, callbacks, and Data) primitives -- that enable state management within the Interactable, and across their dependency tree
This also includes mechanism deciding efficiently, which state changes affect which Interactable)
3) Developer friendly run time helpers to debug and manage the above
----
Cleary A) --> can be a dependency tree of Excel cells, or Matrices, or robot's extremities, for that matter.
Clearly B) (the state) is widely appreciated these day ViewModel (as it is called in Android's new JetPack LiveData components)
The state is also the thing that can be validated, even with TLA+ (which is what am thinking about, in a downtime).
And it is much much easier, in my view to map interaction business rules to state, rather than to UI.
---
I am looking forward to try this with my console UIs project.
---
I also have a strange feeling, that this model will work when I have to manage complex backend interdependencies,
where updates to distributed caches affect the algorithms running across a server farm.
---