Yes the UI would by default reset. But that only matters for stuff that the server doesn’t know about. All the information that lives on the server should render the absolute same no matter which app server you hit. That’s most of the value you get from LV – not needing to jump through hoops to bring stuff you need the server for anyways onto the client in a way it can be updated and react to user input.
Then there’s forms, which by definition pose temp. client side state. LV has means to submit current form values on reconnect, so the server can respond in a way that take those form values into account.
Another given form of client side state is the URL. So things like tabs or modals could change the url, so on reconnect the server will know based on the URL what to do. Another common example of that is search forms or pagination.
You might also have additional client side state that a developer brings into the picture. For those you can use connect_params, which the LV js client can receive and – just like the form recovery – send up on reconnect for the server to account for.
Lastly you might have state, which both the client and the server want to have a say in and that’s where things get more complicated given the nature of dealing with distributed state.
So far for the theory. In practise you still sometimes needs to get your hands a bit dirty to separate purely client side state from purely server side state due to how morphdom works. It wholesale replaces dom nodes without ids and also removes all client side changes unless they’re made in a way for LV to recognise them. If LV would use different means of updating the DOM client side that complexity could be improved upon, but I doubt that’ll happen.
