Please consider my post withdrawn.
i-n-g-m-a-r
LostKobrakai
This is not true at all. You’re correct in that eex and leex templates are processed by their respective view modules, but there’s a big difference in how they’re processed. Only .leex templates (or ~L"…" code) does get detailed change tracking, which allows liveview to send static parts only once and on updates send only the tiniest bits of updated markup instead of large chunks of markup, where 95% are already present on the client. I’m not sure how much, but it should at least help morphdom to make better choices in what to update in the dom.
Plain eex templates will only be compiled to functions returning iodata – no change tracking for parts of the template. Which is why you’d want to be careful to use .leex everywhere liveview is involved.
You’re correct, but if I understand liveview correctly live components also act as kind of a “root” element for updates on the client side / for morphdom. So it could be possible that using components might improve the client side performance as well.
Sorry, didn’t read the whole topic thoroughly. But this can be a solution. If you have to much stuff, reducing the amount of stuff is one way to resolve issues. You can do this either by using client side rendering and keeping data on the client, but rendering only parts (liveview can e.g. work nicely with alpine.js) or by doing the same on the server with more latency.
I’m not sure this is a great description of liveview. Liveview is a great tool to reduce complexity in places where server and client need to interact anyways. It’s a suboptimal solution for any interaction, which doesn’t need to involve the server. It’s also not inherently more secure than comparable js solutions.
3
Matheus
I was having a problem similar to yours, in my case, I have a panel that preloads 40 thousand cards (in the most extreme case), distributed in 7 lists (this is a Kanban style project that I am doing). However, in a more friendly way, I limited each list to appearing only the first 20. And that already starts to return me some delays the moment I execute some action of events, like for example, opening the card modal, creating a tag for the card, editing, moving etc. This delay had a duration of ~ 60ms. Due to the LiveComponents feature that they offer, I chose to share several LiveComponents throughout my project, by the type of communication and properties. Now with this change, I can get an improvement in performance on my panel, due to the behavior of divisions of the HTML bits, but from time to time there are some short delays, which do not get in the way of UX, because it was a very extreme case in which I would carry 40 thousand cards.
2
mononym
Plain eex templates will only be compiled to functions returning iodata – no change tracking for parts of the template. Which is why you’d want to be careful to use .leex everywhere liveview is involved.
You are right in that how they are processed is very different, but my understanding is that the templates enter the processing code as strings. How you interpolate values into those strings doesn’t matter from the point of view of LiveView. As far as I understand it, whether I do <div class="<%= "foo" %>"> or <%= raw(foo) %> where the variable foo is "<div class=\"foo\">" doesn’t really matter as you end up with the same html with the same values will be in the string that is then processed by the LiveView code.
Am I misunderstanding the sequence of events?
You’re correct, but if I understand liveview correctly live components also act as kind of a “root” element for updates on the client side / for morphdom. So it could be possible that using components might improve the client side performance as well.
I can see how that might help in some cases. Would obviously depend heavily on how it impacts redrawing. I’ll take a peek at that.
I’m not sure this is a great description of liveview.
I’m not happy with it either, but LiveView is certainly not at all about making writing the actual html for a page easier which was my main point.
It’s also not inherently more secure than comparable js solutions.
Perhaps I should have said it’s easier to be more secure. Because you’re right, you can make JS solutions secure…at the expense of doubling up all your logic and doing the validation checks server side.
1
mononym
How, exactly, did you implement your components? For example, did you just replace a form element in a LEEX template with a call to render a live component, which did nothing more than render that same form element that was originally created in the main template? In such a case I would love to understand how that would lead to an improvement as it seems like you would still have the same DOM manipulation issues.
Did you also change the overall structure of the page as you also implemented the components?
0
LostKobrakai
It seems you are. LiveView does not process the resulting markup after assigns are interpolated. It only processes the templates. .leex templates are processed, so that static parts of the template are taken apart from dynamic parts. The dynamic parts also have dependency tracking, which allows to update only the parts, which actually depend on the data being updated.
<div class="<%= "foo" %>">
becomes something akin to (pseudo-code)
%{static: ["<div class=\"", 1, "\">"], dynamic: %{1 => %{depends_on: fn -> @foo end}}
where ["<div class=\"", 1, "\">"] can be sent once to the client and only the value of @foo is sent on updates.
… while
<%= raw(foo) %>
would be represented like this:
%{static: [1], dynamic: %{1 => %{depends_on: fn -> raw(@foo) end}}
where the whole raw(@foo) would be sent on each update.
If you now render a .leex template you don’t get back a plain string, but a struct, holding those details, where the runtime can now decide to send only the parts that matter to the client, significantly reducing the amount of traffic on the wire (imagine the above nested a few handful of layers).
Non .leex templates essentially result in the same unoptimized sending as the latter example.
6
chrismccord
Creator of Phoenix
Components would solve your issues in this case. The issue is we have to patch the entire LiveView DOM container for any change, and for large DOM trees, this requires traversing the tree as you alluded to. If you wrap the paragraphs in a component and/or the form in a component, it will allow LiveView to patch only those areas when they change, and also skip walking those areas when the parent LiveView needs to patch a DOM a non-component node that it owns.
11
mononym
Alright then, I guess I’m gonna go write a couple of components and see what impact it has on the performance.
1
mononym
