When your server goes down and the websocket connection is lost, the nprogress bar will show at the top of the page and when your server comes back up, LV will update the page based on its old vs new view of the world automatically.
This can be a very jarring experience for the user because now the page they were actively viewing changed under their feet and it’s out of their control. This is going to be especially disruptive if they are filling out a form, especially important forms like a checkout form to make a payment.
Also I remember Chris mentioning that if you make CSS changes, those changes won’t be diff’d automatically so now you run the risk of having a very broken looking page if you make CSS / JS changes – and the work around for that is to manually change your LV salt and then LV will do a hard refresh of the page.
This type of hard refresh is going to be the ultimate jarring experiencing because it’s like doing a full page reload for the user while they are using your site and it sounds like this would happen even if you changed CSS on a completely different page than what the user is on, since it’s all served from the same bundle.
I think there’s really 2 problems to solve here.
- How to make non-CSS changes less jarring for users
- How to make CSS / JS changes somehow automated without having to manually reset a salt value but also still have control on which pages get that hard refresh (so can it be done without the hard refresh) or think of something that just works in all scenarios without it being jarring
The way the web usually works without LV is, if someone is sitting on your page and you happen to deploy, they won’t know you just deployed and by the time they click the next link they will get the new version and life is good.
Even with Turbolinks, you can add
data-turbolinks-track="reload" to your JS and CSS link tags and it automatically knows to only do a full page transition if it changes, because the file name has a unique ID already (the md5 digest) which means it can get tracked. But Turbolinks isn’t a websocket connection so this works seamlessly in practice in 100% of cases without any special deploy steps.
I don’t think we can apply that same rule to LV because always hard refreshing unrelated pages for a CSS change would be a pretty bad user experience. Imagine changing the CSS to update a contact form’s textarea and having that force refresh the checkout page for 25 connected users.
I think this is a real problem to discuss because a lot of folks deploy to 1 server because it works wonderfully in practice and with a non-LV app it’s very easy to do this without most user connections realizing your server even went down for a few seconds to restart. Even with Turbolinks.
Having to set up a Kubernetes cluster with a load balanced cluster of servers that have flawless connection draining just to deploy the most simple but realistic production ready app is going to raise the bar too high in my opinion.