I will, for sure. I even hold out hope that in some way it might even end up being helpful to you, but that woukd be for you to guage, not me. I do hope that we’ll see you around the project I’m creating as a working space for different use-cases, vantage points, approaches, feedback about what ended up working well and what made life hell to come together as we each go about building our own and/or helping each other build experimental implementations on the data framework I’ve spent some time putting together. Some objective metrics to compare as opposed to the subjective stuff we can never seem to agree on will eventually help us define the smallest possible set of use cases and for each a demonstably best approach with regards to practical liveview. You in?
MarthinL
garrison
I am very avoidant of closed platforms, but if you post examples publicly I will gladly comment on this thread about them 
The work I have discussed on here will be public within a couple months so I will be able to provide some real examples of what I tried and couldn’t make work, if people are interested in that.
MarthinL
Will a public project on GitHub good enough for you then? I’ve gone and created a completely fictitional project whih, while having absolutely nothing in common with my real project I cannot speak about yet either, contains enough use-case overlap to be representative of my needs. I suspect that the bulk of the conversations around it will be easier to have on GitHub itself than on this forum though.
garrison
I post on this forum because it is open and independent, and I appreciate the community here. I choose not to used closed social platforms, GH included, though of course many others do and that’s their choice.
If what you publish is publicly available I will gladly read it, though
MarthinL
You’ve actually caught my code in an awkward spot with a half-implemented change from using a div scroll container to having the whole page as scroll container with a padding for the header because of trouble I’ve seen with touch devices handling scrolling in the container in a widlyl different manner. So what I’ve done is create the project, made some notes in the README.md meanwhile to start the conversation, and I will try to get the code stable and uploaded over the weekend.
My Tree Browser is a public project on GitHub
MarthinL
Pardon my ignorance. Which alternative collaborative project platform would be open and independent enough? I don’t get how you’d want to have several people contributing to one codebase purely via this forum. From what I could see all the development of the platform happens via GH so I would assume all if not most of the folks here also have accounts on that. What am I missing? What factors into your decision about what consitutes closed vs open social platforms? Is this related to efforts to either comply or defy rules and regulations imposed by an employer, government or laws? I respect your choices, they yours to deal with. I have my own to deal with as well, so normally we’d both stay out of ieach other’s choices. When someone’s choice have an impact on another’s life though, that’s when I believe the affected party has cause to either gain a better understanding of that personal choice or take other measures to reduce the impact on them. I’d like you to be able to get actively involved here but you choose to avoid GH, so either I learn why and adapt in a way to accomodate you or make peace with excluding you from proceedings.
garrison
It was not my intention to derail the thread with a discussion about platforms, I was just letting you know that the extent of my “contribution” would be to discuss LiveView/architecture on this forum (as we have been doing).
If you are looking for others to contribute code and so on I am not the right person for that, but I hope you find what you need.
user20230119
Phoenix Framework @ https://xcancel.com/elixirphoenix/status/1924457856884977691
it’s “one level” in the sense that we track if assign foo changed, but the diff for maps is deeply nested, so if foo is a map we diff the tree all the way down and only send the changed subtree/values
MarthinL
Yes, that true, and I make use of that. However, and this is at the heart of the problem, that applies to assigns and not to streams because assigns stay in memory so there is the previous value to compare a new one to. With streams the server does not keep the previous value around so cannot diff and the client has the dynamix parts derived from the record in the DOM but not the whole original record. That’s what’s been cathing folks out when trying to use streams. It’s not as big an issue for linear data like a list of records (though some would say it is) but when it comes to serving big recursive data to large numbers of clients, the option of keeping a potentially explosive amount of data in session memory for detecting changes becomes too expensive to contemplate in a production setting, and that’s where the approach I’m developing come in handy.
I make full use of LVs ability to diff assigns but the idea is to not put the actual record data in assigns. Only structure data goes into the assigns, and only after being restricted at the database level to represent one exacting rectangular slice of the data. You may have a different opinion but from where I’m approaching this that is small, contained and controllable enough to keep in memory so LV can do its thing. Which “data” records are to be sent from the server to the client then becomes a matter of calculating the difference (in set terms) between the MapSet of keys for which there is HTML on the client already and the MapSet of keys the client should be showing after the update and sending the HTML generated for those through using the streams update mechanism. Any record from the MapSet that should be on the serve that we know from the business logic or PubSub subscription has changed since it was last sent through, is also added to the stream and thus updated on the client screen.
I don’t know if this is making sense to you (yet). I fell a bit behind over the weekend with the planned publish of the code I have, but I should have it on the repository soon. That will give us something more concrete to discuss and therefor hopefully somewhat easier. Right now you’re having to guess at what I’m actually referring to so it probably sounds like a load of waffle.
garrison
I think this is referring to static map accesses, documented here. I don’t think Phoenix can diff dynamic accesses, but maybe I’m wrong about that? It just means that if you access @foo.bar.baz in your template then that dynamic won’t be diffed for every change of @foo and @foo.bar.
But anyway, what you need to replace LiveComponents is the ability to diff ordered collections. UIs are generally trees of ordered components, where the order matters very much. You wouldn’t want a file tree where the files are re-ordered whenever you scroll!
But diffing arbitrary trees is very expensive (I believe O(n^3)), so you need to do something to bring that down. The problem is that comparing two children of a given node to see if they’ve been re-ordered requires recursively comparing all the way down the tree.
But generally the changes are small, so what you can do is assign a static key to each child of a given node and then “inform” the algorithm that the same key means the same object, and that keeps you on the fast path. That’s why React does it that way.
Of course Elixir maps side-step this entire problem because they are not ordered at all! Which unfortunately means they’re useless for a rendering engine like this. There was work in this PR to extend diffing to arbitrary collections, with discussion of eventually using it for this purpose (with a key). But I don’t believe that has materialized yet, so you still need LiveComponents for now.
LiveComponents solve this, by the way, because they do have a static key (the id). With the caveat that it must be globally unique instead of unique per-node-child. This is less convenient but does have some theoretical performance benefits over the wire if you move a component to a completely new place in the DOM. Though in practice I’m no longer certain this optimization actually works, as I’ve seen some weird diffs. More research needed.