First time I asked I read your response to mean that it’s exactly that first clause that’s the key but that makes the difference between only the parent, only the children or both being updated, simply because that what I asked about - what in the example makes that difference and that where you pointed. But it can only make that difference if some of the time it gets called and does something other than the default. I understood the load_children function to be a (PubSub-less) simulation of of a chance that impacts the children without the parent and I was busy trying to figure out how the reverse would be made possible - the parent getting updated without impacting the children what was the primary concern at the time.
I’ve been compiling a chart complete example of my own to answer that question if I’m able to pull it off in the first place. That’s exactly why I’ve been engaging to intently with the example and how to does its bussiness and how ran into the befuddling fact that the code I was as lead to believe is the key to the solution.
Not yet being sure how the tools actually work means it might yet find what doesn’t to do impossible.
However, principle is this. (Obviously) for the first (mount)? It will be a full normal render. The tree component will build the structure into which the content is rendered, still fundamentally recursive following the structure element’s recursion. At each level of recursion the children are drawn in from the linear list and rendered into place where they end up getting placed as inner content slots within the parent. Nothing about that is unusual or outside the norm. The only fact that clashes with the assumptions LiveView makes is that the resulting dom is recursively nested rather an a repetition of non-overlapping dom elements.
The differences only come into play when updates are getting involved. I’m still trying to identify and leverage the exact opportunities available to this with, but the general principle is to implement a full set of tree operations at the LiveComponent level. I’m hoping to do most of that in the single whole-tree LiveComponent but it will most likely require that a per-node LiveComponent cooperates in a prescribed manner, much like implementing a behaviour. This would all be towards enabling tree operations to optimise by either preventing or (selectively) absorbing unnecessary changes getting picked up by diffing.
The complete set of tree operations have been largely known theoretically since Knuth’s time, but to make them real enough to program one only needs to look at the things we can do with file systems and their directory structures. It’s a great analogy of a tree and how tree information (directory structure) even though directories are often also special files, are managed differently from the files. The difficulty with the DOM is that in filesystem terms the contents of the files and the directory structure is all in one tree. Our challenge is to create a way to surgically manipulate the DOM remotely anyway.
It was in the context of my attempts to show this working rather than just talking about it that I got caught up in the cognitive dissonance of how Steffen’s example actually works. But that’s now waiting for an answer (sorry, but yours didn’t help me at all) so am forced to describe rather than show.
The overarching concept though is based on the premise that even the most complex, contrived and unpredictable ways a tree and its contents can get manipulated by incoming data or by user interaction can be detected as and reduced to a sequence of primitive changes along the lines of
- saving a new file in a directory
- saving to an existing file
- moving a file from one directory to another
- moving an entire directory from one parent to another
- renaming a file or directory
- deleting a file
- deleting a directory and everything below it
- change attributes which affect access and visibility rights which impacts what is shown in a listing and the order they appear in
- Walk through a directory structure from a starting point with a possible depth limit to look for and/or take actions on each file or directory found
- Work out how much space is used by what optionally summarised or detailed per item.
It is vitally important to note that the tree operations I describe above can be applied on two levels - the big underlying tree or the visual presentation of that tree for one or more users. None of what I am describing here is aimed at manipulating the underlying tree. That part is for you and me to implement however suits our data and our users best. What I am talking about here is to take the things we or our users do with the data and programmatically (largely declaratively) map those actions on what needs to happen to the visually represented trees derived from that data and the changes to it.
In other words, I am not suggesting that we merely detect the require changes in any way similar to what LiveView does with diffing and try to retrofit the deltas to the tree operations. The aim would be to take the actions right there where they are implemented for us or our users to change the underlying tree with and propagate those in tree primitive form (via PubSub) as what the various LiveView component instances currently presenting that data somewhere in a tree for a user must make happen to correctly and efficiently reflect the changes to the displayed DOMs.
If the trees were small enough it would been feasible to keep updating a whole tree at a time which is what diffing ends up doing be default. By limiting the loaded window and taking the bulk of the content (file content) out of the “directory structure” leaving only ids (disk node numbers of files) we’re making the tree small enough to let LiveView do the heavy lifting. What remains is to use our knowledge of the structure of the data, what it will look like in the DOM and what we know is meant to be happening to filter and augment what diff picks up and turn that into the minimal updates that needs to go to wire.
Update: I eventually found where the first update clause gets involved. I expected it to play a role in the “Load Children” test case while it actually plays its part with the “Rename bar.txt” test case. The reason my changes broke the “Load children” case is not related to that clause.
It works especially well for me because in addition to the labels (like folder names) the content I need to display for each node is in itself a multi-line block of yet another instance of a tree display (my second use case for the library). The third use case is stranger still. That one’s derives from the fact that the data I display isn’t truly a tree but in some respects more like an inverted tree or network in that a node can have multiple “parents” or children in a different hierarchy. So if the user has navigated to some place in the tree or the “field of trees” they’ve walked into, they can choose an option to turn around and “look back” from there to see that other “tree”. I know that doesn’t make a great deal of sense at this point to anyone but myself, but it will become apparent in using the application.