Checking for a new version of an Elm app

Hi everyone,

Suppose you have an Elm web application, which may be kept open for some time. At various times you may update the application (on the server), and what you would like is for some kind of alert to pop-up on an existing user’s screen to say that there is a new version available, perhaps with a button to refresh the current page.

I think this is relatively standard and was basically wondering what people’s solutions to this are? In particular is there a standard way of doing this that my searching has not found? I suspect there are multiple ways of doing this with various advantages/disadvantages. Does anyone have any thoughts on this? Especially interested in anyone with experience of implementing this in Elm, but any thoughts will be appreciated.

I don’t know of any standard approaches to this, but I can share how we do it where I work, or at least how we did it last time I looked at the relevant code. This is mostly a JS (Ember) app, so there’s no Elm involved in this process, but the same techniques should work fine in Elm.

When we generate the app, we embed a unique identifier for that version in index.html, as a meta tag in the document’s head. Then in the app, we fetch index.html on a 30-minute interval, parse the version out of the header, and if it’s different than what’s currently running, prompt the user to refresh.

One nice thing about this approach is that index.html is the browser’s entry point, and all CSS and JS assets get a new URL on each release, so there’s no way for the detected version to be out of sync with the reality of what’s deployed. The downsides are that we’re fetching more data than is strictly necessary, since there’s a bunch of other information in the HTML unrelated to the version, and that pulling the data out of the HTML is a bit more complicated than it would be if we were just fetching some JSON. That said, since we have fully control over the structure of the document, we could almost certainly get away with using a regex to pull out the version rather than a full HTML parser (we might actually do that, I don’t recall).

Hopefully that’s helpful, but feel free to follow up if you’re interested in more details. I’ll be back in the office tomorrow where it’ll be easier to look up the actual code involved.

1 Like

Thanks that’s very useful. The scheme we had in mind was very similar. To avoid the parsing we thought that when we generate the MAGIC_NUMBER, we could update the index.html and generate a file version-MAGIC_NUMBER.text. Then the front-end just needs to make a static-file request for that file and if it gets a 404 then it knows it should prompt the user to update/refresh. This means that if you make small changes you don’t need to delete the previous magic-number files, when you do want an update to prompt the user you just delete all the previous magic-number files.

I guess the specifics aren’t really all that important, I just didn’t want to go down this path and do all the implementation only to find that there is a standard way of doing this. Thanks again.

Thanks, that’s an interesting idea of just reloading every N days rather than try to determine whether a reload is necessary, that might actually be the most appropriate thing for us. It’s also interesting that some people are checking the version on every API call. We actually have a requirement that inactive users must be logged out after a certain amount of time with no interaction, because some interactions don’t involve the API we send a “don’t-log-me-out” ping and we could easily use that to also check for a version update. The downside would mean that it wouldn’t work for non-logged-in users. Nice thread.

I think this presentation from elm europe is particularly relevant to your question

1 Like

Thanks! I can’t see how I would have found that by searching.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.