Updating a SPA automatically without browser refresh

I was asked a very interesting interview question today.

Lets assume you have a single page application running on n users computers as a dashboard and you updated the application, how does all of the clients receive and manage the updated assets without incurring a browser refresh.

The first problem to figure out is how do I know the application was updated?

1. Polling the entry bundle asset
2. Polling the Index.html and comparing hashes/versions
3. Polling some custom tiny server text doc
4. Dashboard websocket contains the version
5. On acquisition of new data it contains version
6. We don't update until a change of route

Now we have a version, we distinguish that the server version is 'greater' than ours. How do we acquire the new asset?

1. System.js
2. We fetch or receive it via 'AJAX', create a 'script' tag and allow the DOM to parse it. This bundle would have to include updated assets or links to lazy-loading all other required assets & template changes.
3. We fetch a 'version diff' file which tells us which files have changed, we then request those updated files.

What are some gotchas in any form of updating a SPA without a browser refresh?

1. Removing existing variables could be a memory nightmare, especially since we don't have direct memory management.
2. Mutating existing variables could be a management nightmare which could result in significant debugging issues if some parts of code were relying on old code that's no longer available for example.
3. Attaching scripts with each update would require removing of older scripts for cleanup assuming the system was never refreshed for many years. We don't want the DOM to get too big and unwieldy.
4. After acquisition of new code, the new code could have managed response data much differently, so it's more easy to just re-acquire any data required outside of the javascript asset to fulfill the page.
   1. This makes the whole thing almost a moot point as we would thereunto almost incur the same load as an entire page refresh.
   2. If we didn't want to reacquire all data then it would need to be stored pristinely outside of the application in the case the application updates the data can remain unaltered and intact.
5. What happens when the api actually updates to an incompatible version? This is usually something you never want to do, but sometimes it's necessary.
   1. In such cases it would make sense to change the resource name to not break existing clients that have yet to update their dashboards.
   2. We see that an updated client is beholden to an updated api release. These both should be done at the same time. Having a refresh could make the most sense.
6. Before we rashly jump into a new version, we need to make sure that the user has saved any changes - or we decide that it's important to our ux to query the user whether they are ready or okay with updating the application.