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.
