I'm working on a big app with Inertia. When the version of the js files change, I don't want a hard refresh, as I find it rather disturbing to the user, and it could lead to loss of data. I wish there was a way to intercept when the version changes so I can do something else instead, for example show a notification like this:

Possible implementation:
import { Inertia } from '@inertiajs/inertia'
Inertia.onVersionChange(function () {
// Show notification that new version is available
return false
})
The return false could indicate that Inertia doesn't have to do a hard refresh, but carry on as if there was no version change.
Interesting suggestion, although I'll be honest, I'm having a hard time understanding how showing a popup to the user telling them a new version of the app is available, and making them click refresh to get it is less disturbing than simply doing an automatic full page visit to where they were intending to go. Yes a full page refresh isn't as slick and smooth as a typical Inertia visit, but in my mind it's stil much better than making the user think about this, and forcing them to take action.
Hi Jonathan, thanks for your reply! In most situations I agree. However, I'm currently building a pretty big app with several advanced UI features, such as overlays that do some work and stay there when you're switching pages. I recorded an example when uploading a bunch of files (warning: UI unpolished for the moment ๐ ):
[redacted]
As you can see, the upload box in the lower right corner of the screen stays on top of the app while I'm clicking around. It is exactly this type of wonderful UI stuff that the architecture of Inertia allows for.
But if an update would happen in the middle of these uploads and I click to another page, I would lose everything with a hard refresh. I also make use of the history state (like Inertia does for the remember feature) to keep data preserved when you switch from one section of the app to another. Such things are lost as well when doing a hard refresh.
Hey Klaas, thanks for that explanation. That makes more sense to me!
I wonder though, is your suggestion enough in this situation? My concern is that, when the assets change, all subsequent Inertia.js requests will be prevented until the assets update, since they will all return a 409 Conflict response. Is that okay?
Meaning, if a user chose not to update (click refresh), and continued using the app, the very next Inertia.js request would cause the same prompt.
Basically, I think this would require some additional step that tells the server that it's okay that the assets are out of date. Maybe X-Inertia-Version: IGNORE or something like that.
Hi Jonathan, you're completely right. I didn't think of that side effect. Such a header would be a good solution, indeed!
So, I've been thinking more about this problem, and I think there is a simpler way of handling things when you want to take asset refreshing into your control, removing the need for some type of version change ignoring. Here's how to do this.
- Inertia::version(function () {
- return md5_file(public_path('mix-manifest.json'));
- });
Inertia::share([
'version' => function () {
return md5_file(public_path('mix-manifest.json'));
},
]);
watch: {
'$page.version'() {
this.showNewVersionMessage = true
},
},
The only requirement here is that you use persistent layouts, otherwise the message will be cleared away when you move to new page.
I just tried this in the Ping CRM demo app, and it works awesome. ๐

Given how well this works, I am going to close this issue. Please tell let me know if I missed something obvious though, and we can always reopen. ๐
Wow, great! Sometimes we are looking too far and there are much simpler solutions ๐ Thank you!
Haha, yup, totally! Guilty! โ