sid597
commented
1 day ago 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
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.