Closed AllanOricil closed 1 year ago
Right, the way the snapping behaviour works in the library is by connecting to the bottom of the blocks, so you wouldn't be able to connect the first one. I think it's pretty intuitive so I don't plan on adding new behaviour that would allow for connecting a block above the first.
That said, I obviously would like to find a way to allow for that somehow. Maybe a method that adds blocks programmatically inside the tree (since I am planning to add a custom delete block anyway). Or maybe implementing multiple trees, which would then make it super simple and straightforward to add blocks above the root parent (if you have two separate trees, you could drag an entire tree and put it below the other one).
So yeah, while I don't plan on adding new behaviour in terms of dragging and dropping blocks above the root, I am happy to explore other possibilities to allow for what you have described.
@alyssaxuu what if we think of the whole tree as a virtual dom tree? Every time there is a change to the tree we can go through each node and see if we need to re-render or render something new. That should be quite straight forward to implement once we have the render function separated.
This sounds similar to the proposal for inserting between 2 blocks in my mind https://github.com/alyssaxuu/flowy/issues/58#issuecomment-619185613
Show a blue snapping dot at the top of the block and it inserts it before as a parent, whereas a blue snapping dot below the block inserts as a child (block can have one parent and multiple children)
If I could at least release a block anywhere then I would be able to connect the current root bellow this new block to create my new root. But in the demo I can't leave a block in the "canvas" unless I snap it bellow some other block.
If I could at least release a block anywhere then I would be able to connect the current root bellow this new block to create my new root. But in the demo I can't leave a block in the "canvas" unless I snap it bellow some other block.
Yup, that is on purpose. It's meant to keep the library simple, and the trees clean & easy to understand (together with its auto-rearrange functionality).
It is something I have been exploring though for creating multiple trees, although I would still like to ensure that the canvas area is clean and blocks don't overlap.
I tried to drag and drop a block on top of the root and it did not "snapped" there. I would like to add a new root to entire three.
example: After setting up the example in the image, try to add a new block above the root one. You will not be able to do so.