LiveView append and performance degradation with large number of appended elements

You may want to take a look to the video from Chris McCord where he builds a Twitter clone and see how he is appending tweets, instead of triggering a full render of all tweets in the page:

Unfortunately he doesn’t provide the link for a Github repo, but if you take a look to the topic Where is the chirp repo for the real-time Twitter clone in 15 minutes by Chris McCord? you will find several links to different repos and discussion about it.

I am already using temporary assigns and appending to the DOM. The update happens exactly as in that video with small chunks of html being sent over and the update happening very quick…when there are a few items on the screen like in that demo.

My issue isn’t triggering a rerender of all messages from the perspective of the server, but that slipping these tiny chunks of HTML into the DOM is triggering a browser redraw in some cases and it’s causing huge spikes in apparent lag due to the browser freezing up while it scans the DOM to recalculate stuff.

Now what’s a bit odd is that while replacing the form in place takes a huge amount of time, I can perform a click interaction elsewhere on the same page that inserts and removes elements and it takes almost no time at all. So the redraw being triggered and it taking a while is happening only in a couple cases, apparently based on the relative position of those elements to the huge list of messages I am inserting as that last quick case happens “to the side” of where the messages are displayed.

This may very well be a browser limit thing I can’t get around and I have to get fancy with some tricks like I mentioned in the original post (using JS to shift incoming messages into the existing single “mega message”) but I lose some flexibility that way.

Part of me is almost wondering if I’m going to need to keep the messages server side and allow the user to “scan” through their messages up and down using hotkeys and swapping out what messages I show based on state. Much how many client side JS libraries handle large collections to keep performance good.

So I am new to Live View and still in the learning process, but I was wondering if you are rendering each message as a live_component, using socket update instead of assign, and at same time adding phx-update="prepend" to the for loop rendering the messages?

Maybe you could share your code or repo so that the experts here can help you better then me.

I’m not rendering a series of live components as I don’t need that complexity for the messages. However, other than that I’m doing almost what I’ve seen done elsewhere. However, rather than injecting values into an html fragment, I instead build up the HTML elsewhere and send it over to LiveView to be injected raw, rather than having values interpolated in. So my message might actually be: "<p>Goodbye <span class="emotion">cruel</span> <span class="place">world!</span><p>

Skipping the rest of the layout because it’s not important, but this is in my client.leex file:

  <div class="w-3/5 flex flex-col">
    <div id="story" phx-hook="Story" phx-update="append" class="border-4 border-r-0 min-w-full flex-1 flex flex-col overflow-y-scroll p-2 font-extrabold font-story">
      <%= for message <- @messages do %>
        <%= raw(message) %>
      <% end %>
    </div>
    <div class="h-8 flex flex-col">
      <%= form_for @input, "#", [phx_submit: :submit_input, class: "flex flex-col flex-1"], fn _f -> %>
        <%= text_input :input, :content, phx_hook: "Input", phx_blur: "stop_typing", placeholder: "Enter Commands Here...", class: "min-w-full rounded-lg resize-y min-h-full", autocomplete: "off" %>
      <% end %>
    </div>
  </div>

The return for my mount:

    {:ok,
     assign(socket,
       character_id: session["character_id"],
       input: Input.new(),
       messages: [],
       client_data: client_data
     ), temporary_assigns: [messages: []]}

Are you sure this is the culprit?
Are you also doing other LiveView stuff?
For example, once I had some component rendering an inspect of some state and it was killing performance.
In the mean time I was investigating the wrong LiveView for problems.

It looks like you are defeating the programming model of Live View here that is built to avoid precisely this “complexity”.

From my understanding in a for-loop you will want to use a live_component so that live view can properly track the changes and be able to do its amazing diff to only send the values that have changed to the client, not the html. Live view engine separates static from dynamic parts, but you are defeating that in your code, or if you prefer you are working against the program model of live view.

The culprit is a large number of individual DOM nodes on the webpage causing a very long redraw operation by the browser. ~50ms just to insert a single message into the div containing all of the p elements containing the individual messages.

Appending a message is pretty quick, relatively speaking, but swapping out the form/input by creating a new changeset (which triggers LiveView to send over a new form HTML fragment) takes over 500ms when we’re talking hundreds of messages. This happens because on my webpage the design is that the window containing messages sits directly above the text input field, so replacing the form means the browser takes a look at everything above it and it forces a redraw calculation of the form, the window containing the messages, and the hundreds of messages within the window.

I have a completely different LiveView interaction on the same webpage that happens in another ‘column’, and it’s still quick even with hundreds of messages. So the culprit is absolutely browser redraws/calculations when elements are replaced/added to the page in such a way that things have to be recalculated.

This is why I asked how people are handling having large numbers of messages when using LiveView and appending/updating the page, because that’s where the issue comes from.

To be fair this is also a problem with pure client side libraries and the reason why e.g. many client side frameworks have components, which render just the visible rows of lists instead of every available item.

It looks like you are defeating the programming model of Live View here that is built to avoid precisely this “complexity”.

I think you are misunderstanding LiveView, what it is, and what it is built on. The templating system EEX which LiveView is built on has been around since much earlier Erlang. All of the templates you see, whether the normal EEX templates or the LEEX templates, end up being processed and turned into strings after which is where LiveView comes in.

Using EEX absolutely does make it easier to write things like loops and create complex interfaces, but that has nothing to do with LiveView and is not a functional feature of LiveView at all. LiveView works just fine if you take EEX out of the equation entirely and write everything by hand.

From my understanding in a for-loop you will want to use a live_component so that live view can properly track the changes and be able to do its amazing diff to only send the values that have changed to the client, not the html. Live view engine separates static from dynamic parts, but you are defeating that in your code, or if you prefer you are working against the program model of live view.

For loops have nothing to do with Live Components. A Live Component is simply a way to encapsulate state (in some cases) and display logic in an easily reusable way, much like templates. That demo only used LiveComponents because it was effectively writing a bunch of cards to the webpage, each with like buttons and other interactivity. If you don’t need to encapsulate state, because you’re just writing out some text, you don’t need to use Live Components. That’s a red herring.

LiveView is about replacing JS as much as possible to provide richer UI experiences and to provide for a whole new set of interoperability between client and server out of the box while keeping as much server side as possible to reduce context change, development context switching, and improve the security and integrity of data. All of the templates, for loops, and everything else that makes building the actual HTML easy is outside LiveView’s bailiwick.

Which I called out explicitly in the initial post. And hence my asking, in the first post, how people are approaching it and even gave the idea of simulating that using hotkeys and “scrolling” through the messages that way.