What is the design of hierarchical reactive components?

[sid597]

Should be callback free, emits a new event goes to stream. Listens to stream for events targated to it.

The abstraction I want each component is that it can be connected to n no. of streams and can figure out if the event is for it. Outputs its side effect to a global stream.

[sid597]

hierarchies: visual , actions
transformation from visual to action hierarchy.

model action hierarchy same as visual? or make it its own intuitive one and find the translation b/w them?

examples: rectangles on a canvas.
ifMy intention is to move a rectangle, i click.
what does thi click mean?
from visual pov background his the furthest, rectangle on top of it, if there is a button in the rect, then the button on top of rect. think of it as z-index, button-2, rect-1, background-0

from action pov the. hierarchy is differentonce I click, turns into event.
read by all comps in the screen space, each comp has to decide if its for him but since there is no callback and compononents dont care about anything external to them they have to decide by the different events they receive.

Background can't see the [x,y] and decide if its for him. background can only know iff no other components claims it. .
so the dependency for background is the big components in it i.e the rects in our case.similarly rect has a dependency on its buttons.

[1] -> but background does not have to wait for the buttons to decide and then the rects decision for it to know if the event is for him. The background can decide it at the rects point of decision itself. Hmm so say there are 4 comps for each visual tree path i.e background->rect->box->button for each rect in the background. if we click on a button then there will be 4 "yes its for me" but the background can decide with only one yes, hmm so each comp, can look at one of its children from the visual hierarchy tree to decide if its for him. The efficient way to do it is to only look for its children layer and not all the decendents.
For each click on a component, the component for sure can say 2 things:

• its not for it's parent
• for him or his children. [2]

in action hierarch there is no control over what

decision streams, how many events do you need to look at to decide? for visual its 1 I think just take the tree structure and go layer by layer

{:b
 {:style {} 
  :children [{:r1 {:style {}
                   :children [{...}]}
                          ...

I think the action hierarchy is '(a)live`, hmm don't have the right concepts but it goes like this. there is hierarchy but cannot capture it via the structure only via communication. Because all the components get the event concurrently, then different comps wait on diff. data to make their decision.

ok so now I can see the hierarchy and I think we can capture it in a structure, now have to figure out that structure. ok so the structure is in the event itself. [1]

[2] -> I think I have much better understanding since I started from the wrong understanding and maybe a plan for attack and testing it

[sid597]

Note: the above is for one action type, so still have to understand and design from general action type pov

[sid597]

I am thinking about this for the click case. Thinking about how to do this if the problem is what I assumed above then its very fun to think about but if I look at the problem statement and observe how the current system is then what I am thinking above is over engineering. Clickable components in the ui are very few, so I can just subscribe to the click stream directly, each element in the view does not need to have a built in click listener because its meaningless.

Click is used for: finding which element is in focus, actions on a button, checkbox, radio box, dropdown, collapsable, input.
these type of elements in the ui are going to be very small.

In my specific current case of exploring discourse graphs the no. of clcikable elements are very low, its mostly about visualisation, and more intutive and intellegent algos and ai instead of manual clicking.

[sid597]

I think observing what the system is going to be would give me a better direction instead of thinking for a general case its very fun and fulfilling but over engineered, not incremental, not "quickly" testable. I believe in feeling and playing around to learn a thing and doing it the general way takes that away from me. I tried to do this top down but I think I should let it emerge although I see the catch and common pitfall here which I am trying to avoid by building the all encompassing system but I think I have a better understanding and sense than others when it comes to not going to the absolute detail and perfection. I am able to go deep enough and not get stuck in trees such that I forget the forest, might be the other way for me but thats perfect? for this project.