Hi, there’s a whole long TL:DR going on about Recursive Trees in LiveView for context, but in the process of formulating a solution there is one thing that can be done to a tree that I’m struggling to figure out how it could map efficiently onto the wire (for component updates as well as via PubSub) and the dom operations it triggers client side.
As the above discussion has started doing let’s stick to using file-system directory structure as commonly understood metaphor. In that vein, the operation I’m having trouble with would be similar to
mv /dir1/dir2/dir3 /dir1/dir15/dir3
meaning to reposition the dir3 folder and all of its contents from being a subdirectory of /dir1/dir2 to become a subdirectory of /dir1/dir15.
I don’t have any morphdom experience or prior exposure, and most certainly don’t understand how LiveView uses it, but from a naive observer’s perspective there does appear to be primitives in morphdom that could achieve this.
In the best case scenario, it would automatically be taken care of if I simply update the dir3 node as a child of dir15, but have no idea if the parent relationship is visible or addressible anywhere.
I also thought of creating a new empty temporary node at the destination and make that look like the source node through updates in the hope that diffing and morphdom will notice its the same content and move it but i run into the same problem as above with added undertainty if it’s even possible to change the id of a LiveView component after it’s rendered.
This may seem trivial, and perhaps it is or could be, but in deeply recursive trees the impact on the user would be comparible to miving a directory through the GUI (especially windows) or from the command line with the mv command. The latter being completed instanteneous since it’s really just a pointer change and no uswer interface needs to update, while the former tracks progress as it traverses through the structure to collect what copies to make, shows progress as it copies each file and once done it completely refreshes the display. I’d love to avoid that approach if possible, and I think the brower’s DOM itself is quite capable of displaying it post-change very quickly, but I need help figuring out a reliable high-levlel approach to “trick” LiveView into giving morpdom the correct instruction.
Even if it means dispatching a custom message to the client which directly instructs morphdom to apply the move directly to the DOM before makeing the equivalent update to the LiveView which will then look to morphdom as already done.
Or perhaps the resulting JS on the client would just brute-force change the id for the root of what consitutes the dir3 node to a temporary value so that when we insert a new child into dir15’s LiveComponent with that same ID morphdom would pick up that content and move it into the new node. Then we might change the id back eiher through the LiveComponent or directly.
Or, it strikes me now (this is an edit), I could do a send_update from the LiveCompoent of either dir2 or directly dir3 to the component for dir15 to insert the content as a child, and hope/trust/know/why/how liveview diffing and morphdom will pick it up.
I don’t know, I’m just throwing out ideas, and would absolutely love hearing from others more familiar with the environment about how this an be acheived. It’s not the end of the world if such a change results in a big rerender and update, as I believe it shouldn’t happen all that often and if it does it might not be a bad thing if it happens slowly so the user can follow what’s happening, but it would be good to have some idea beforeharnd about if and how it could be done.
P.S. Is the “parent reference” in nested Phoenix.Component and/or Phoenix.LiveComponent instances stored explicitly or is it effectlively only kept on the call stack as these components invoke each other?