You should not expect more from it since that is exactly what it is for, just like for normal assigns including record sets in assigns, you provide a mapping between the data and its HTML, and that mapping is in that sense one-to-one.
For normal assigns and streams alike, the code performs the magic it’s been taught to perform which in this case means reflecting on the assigns using the metadata to do the diff and look for opportunities to minimise the updates resulting from changes by re-rendering only the changed parts and sending those DOM fragments to the client. But when it cannot isolate the changes it has to rerender the whole assign, list member or stream element. While that’s usually not too heavy a price to pay, really large assigns, list elements within assigns or stream elements such as what happens with recursive structures will mean that when the code reverts to rerendering the outer structure it has an explosive impact. So the impact is big and the chances of it happening increased because of the complexity of the data. Together that means complex data has a high risk of causing unwieldy updates. I seem to recall that both the documentation and the code when it can detect issues at compile time warns about several things in this regard.
It can for example only pick up on the strcuture of the streamed content if you reference the stream in the prescribred way inside your components.
As another example it warns (with explanations) to not manipulate assigns inside the heex template (but beforehand if you need to).
So yes, absolutely, true and justified, without additional metadata neither LiveView nor Streams can do a whole lot more than it is already doing. It simply hasn’t been taught the additional magic required. When we come with our recursive data, it is up to us to find a way to reduce what we give to tools to what they can handle, and that means it’s up to us to limit what we put in a stream strictly to things for which a suitable one-to-one mapping to HTML has been declared and stick to the rules that allows LiveView and Streams isolate independent changes for which it knows how to propage the changes. I’ve done some of that in my app and you’ve chosen to go about it a different way the actual details of which escapes me still.
Now my quest is to see if maybe Streams can be taught some of the additional magic I’ve been using so that it can handle recursion in stream data more efficiently.
Though it doesn’t qualify as a feature implementation (it’s simply something that has to be there) I happen to have implemented that behaviour recently and it was a complete non-event. In the heex template I render the node either as a (<a>-based) leaf item or as a (<details><summary><a/><ul/></details>-based) node.
Of course that by itself does nothing to address the issue of recursion, but I genuinely do not see where this complex body of special case code you keep referring to is meant to be inserted or what it looks like.
If I’m misunderstanding and/or misrepresenting you it’s without malice and purely because I cannot picture where and in what context or even language these special cases you’re talking about lives. I keep hearing you say that it lives in the frontend and you make frequent references to React, DOM manipulation and even jQuery as the old way to do it. To me that implies the code you’re talking about is hand-written Javascript (or using something like React) but either way running on the client and directly manipulating the DOM. The way I use LiveView and Streams I don’t have the foggiest of ideas how to manipulate the DOM and neither would I want to have one.
The only DOM manipulation in my world is done through what I can let Phoenix and LiveView do by providing them with the appropriate mappings. When I cannot provide such mappings the onus is on me to rearrange the server data so that I have data for which such one-to-one mapping can be defined. Based on what I read in the documentation, articles and this forum, that’s more or less what everyone does and keeps doing until the problem has been broken down into small enough sub-problems to pre-calculate the data in a form for which the mappings to HTML is simple enough for LiveView and Streams to effectively keep track of. It sounds ike you’re doing something else, or while you were using Streams ended up doing something different which broke the assumptions of Stream and forced it to rerender massive chunks everytime a coconut drops.
Between your words and my frame of reference I understood that the way you responded to (or at least tried to for a while) that (Streams resulting in runaway update sizes) was to do (a whole lot of) additional DOM manipulation somehow related to using the Stream API. If that’s not the case by all means correct with what you actually did.
OK, you keep quoting this. Apart from having an issue with throwing articles at people to make your point for you, this article is particularly far outside my range. Just from the title I know that I am in absolutely no position to even try reading the article, it’s just too far outside my frame of reference.
Remember, I’m not an experienced frontend programmer trying my hand at designing and building systems but a experienced Systems Architect (and visionary) forced by circumstance (of my own doing) to produce the frontend my system needs by means whatever most appropriate. I’ve never used React, never installed or wrote a line of jQuery code, try my best to avoid bringing any additional frameworkds like React into Phoenix LiveView equation. I dabbled a bit with the Vue concepts back in the day when I thought I could postpone writing a proper server and build some Vue-based SPA with a backend in Laravel, but then I migrated my efforts to Phoenix and replicated a year’s worth of progress within a week so I pivoted to write a proper backend and produce a frontend coded in the same language.
Which is a long way to say I haven’t read the article and won’t be reading it cause I can’t. You’re the one who understands the artiicle so just tell me what you wanted the article to tell me. Who are “we”, why would react need saving, what makes it worth saving, is it not saved enough by others like LiveView (in your words) having adopted its most useful parts as its own?
Again we’re at risk of wandering off topic. I really don’t want to get caught (again) in a discussion about how bad Streams are, and/or DOM manipulation code. I want to make my data better aligned with Streams so I can utilise its (paging) benefits for the intrinsically recursive data my app needs to present to users in HTML.
Perhaps for you issues with Streams, and because I misrepresent you, you’ll be better off starting your own discussion focussed on that. I don’t want this war of words to distract from the constructive discussion I’m trying to initiate.
