LiveView streams cannot survive reconnect?

ademenev

Ok, I admit, the title is clickbait.

There are some examples about using streams, including LiveView documentation. They all look beautiful and work nicely. Well, until the socket reconnects for whatever reason. So, for example, on mount we load a list of latest chat messages, and as we scroll up, we load older messages. And when the socket reconnects, we are back to list of latest messages, and no historical messages loaded while scrolling.

I was not able to overcome this, so I am wondering, is it that streams cannot survive reconnect or that’s just skill issue?

5 comments

/phoenix #liveview #liveview-streams

0 599 5

2025-03-09 07:22:23 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

LostKobrakai

You’d retain the current page (e.g. in the url), so that the reconnect wouldn’t load latest messages anymore, but the current section the user was looking at. You’d loose the other messages “off screen” instead, which would be loaded again on further scrolling.

Stream do however not attempt to retain any data across remounts. If you need caching like that you want to look at other options – like phx-update="ignore" and some client side code to deal with updates.

Post #1

ademenev

Well, if we stay on chat example, that’s not the UX a user would expect.

Post #2

josevalim

Creator of Elixir

It is obviously up to you to implement the UX the user expects. Especially because the root cause of the problem is not caused by streams.

The basic use case of streams is to not send the data on every update. An example scenario without streams is: “I send all of the data on mount and, once a new item is added to the collection, I resend the whole collection”.

That’s obviously expensive, so streams allow you slightly change it to: “I send all of the data on mount and, once a new item is added, I only send that item”. In this example, if you lose the connection, then you will get back to the same page, because you still send everything on mount. So streams do not naturally exhibit this issue.

The root issue is that you are not sending the whole data on mount (and indeed, you should not). For example, imagine that instead of streams, you always send the last 100 messages, on mount and every update. That’s not efficient and it would still have the same issue after the 100 messages window.

Of course, the solution depends on what you want to achieve. The simplest is to store an index in the client and fetch all messages after that index on mount. But you could try to be smarter and cache it locally. Do you want to persist across reconnects? Or even if the user refreshes the page? How much data are you willing to refresh? Also keep in mind that, even if you store in the client, messages can be deleted and updated from the server.

A hammer will help you build a house, but it won’t build one for you.

Post #3