Open john-hu opened 5 years ago
I will try to use Solution 1 and create an internal controller to handle the cache, Hierarchy Builder. We will change the interface of onLayoutChange from difference to the ReactChildren component.
~TODO: we should handle the movement at the same container~
TODO: the key field of the generated ReactNode is already filled ?!.... For example: a node without key is filled with “.0”, a node with “div” in key is filled with “.$div”. This may be caused by the usage of createElement with apply.
TODO: We will try to use HierarchyBuilder
as the bridge to share the information between DesignPane and ComponentTree. The user can layout ComponentTree and DesignPane by their thought.
We can use the React Node and React Children as our component tree. But it is not easy to traverse back and forth among the tree. The most inconvenient parts are:
It is hard to find the container of a node. When we try to move a node to another container. We don't know where we should remove the node from.
It is impossible to keep the original React Node when we try to re-order its children. If we change any property or the children, we should use
React.createElement
orReact.cloneElement
to do it. Once we use it, the original React Node is changed.The possible solution is to break one promise (solution 1):
Another alternative is to introduce an intermediate data format, like the Component/Container class of Java (solution 2).
Pros of Solution 1:
onLayoutChange
event. So, users can just use it at the runtime.Cons of Solution 1:
key
props will be added to the newly created componentPros of Solution 2
Cons of Solution 2