Not quite. Let me try to demonstrate what I did but in the context of the (simpler) files/folders example.
There are three database tables with corresponding Ecto schemas: nodes, files, and folders. The nodes store the structure of the tree and contain foreign keys pointing to files and folders. The files and folders tables then store metadata, like names and so on.
%Node{id: 1, folder_id: 1, file_id: nil, parent_id: nil} # Root folder node
%Node{id: 2, folder_id: nil, file_id: 1, parent_id: 1} # File node
%Folder{id: 1, name: "elixir stuff"} # Folder metadata
%File{id: 1, name: "elixir.jpg"} # File metadata
This tree only has two nodes, but you could imagine an arbitrary filesystem structure. Now, you could write a recursive query to load the tree from the database. You then might join every Node with its associated Folder or File to get the whole tree.
The annoying bit, though, is that now if the user updates a folder (a rename, say) then the new version will come in over PubSub. And you have to recursively walk the tree, find that Folder node, and update it. This is valid, but there is another approach: use indirection.
Instead, you could avoid joining the files and folders to the nodes in the query, and instead load them separately. Then you can store them in maps (files = %{file.id => file} and so on) and join them at runtime by looking up the File for a file_id on a Node.
Now you can simply update the folders map when a new Folder comes in over PubSub, and then it will appear next render. I think this is in the same vein as what you are talking about, but correct me if I’m wrong.
There is one problem with this approach: LiveView is not smart enough to diff the arbitrary folders lookups, so any change to folders would re-render the entire tree and send the whole thing down the wire. I avoid that problem by materializing the tree myself into a simplified representation which I then pass to the LiveComponents. So the “simplified tree” comes out looking like:
%{
id: 1, type: :folder, name: "elixir stuff", children: [
%{id: 2, type: :file, name: "elixir.jpg"},
],
}
This might sound like a lot of extra complexity, but my use-case is very complicated because the UI is highly interactive and has a lot of moving parts. I iterated several times before arriving at this design, which I found to be radically simpler and more performant. Your situation may vary of course.
