Client side errors after deployment of new version

[Marcdj-02]

Since a few weeks I've been catching errors with the ErrorBoundary. I've added a little post request, to report that an error has occurred. Now I noticed that after a new deployment (which happens at night), that a lot of errors occur the morning after. This only seems the case when the data format from the loader has changed. Therefore my assumption is that the javascript code is cached or data is requested via the fetcher and thus not SSR.

Is there any way to (automatically) force the user's browser to update the javascript files and prevent such errors?

[bondepike]

I need solving this problem also. Did you ever find a good solution @Marcdj-02 ?

[Marcdj-02]

No, I haven't

[sergiodxa]

Is there any way to (automatically) force the user's browser to update the javascript files and prevent such errors?

Remix doesn't provide a way to do this, but you can do it yourself.

First, the problem happens not because JS is cached, but because you have users that are not closing the app, if the user A opens your app today and never close the tab in a week, it will keep using the old version of JS, which can expect a different loader data shape.

Aside of the recommendation to try to avoid changing the shape of the loader's data in a way that's incompatible with old version (aka always add keys, never remove them), you will need to detect the current version of the JS client-side and the current version of the JS server-side.

Client-side, you can access this value window.__remixManifest.version to know the build version of your app, server-side this value is available in the build.assets.version in your HTTP server (you need access to this or you need to import the build file).

You can then expose the server build version from a resource route (e.g. routes/api.version.ts) and use a fetcher to request this endpoint in an interval (how frequent depends on you, it can be every second or every minute or every hour), do this in your root component so it's always mounted and if the client build version is different than the server build version, you can either force a page reload or tell the user to do it.

I would recommend you to tell the user to do it, in case they're working on some form and you want to ensure they don't lose any data (unless you keep the draft data in localStorage).

Another option could be to add the reloadDocument prop to every <Link> and <Form> and <fetcher.Form> which will mean the next time they navigate or submit a form it will do a full page refresh.

[bondepike]

Thanks I did not know about window.__remixManifest. My customers never closes or refresh the app so this will come in very handy.

Your copy here is very good maybe it could be included in the documentation.

[iwan-uschka]

Thx @sergiodxa for the explanation and thx @Marcdj-02 for initially creating this issue. It sounds like a good (and probably the only possible) strategy to compare client version against server version to ultimately check, if the frontend is up to date.

I couldn't find any documentation on this so i did a bit of digging and found out that handleRequest in entry.server.tsx (https://remix.run/docs/en/main/file-conventions/entry.server#handledatarequest) has a prop remixContext containing manifest.version.

@sergiodxa can you tell us, how version is set? I compared the value of version for two different builds (different code) but it didn't vary. How is version properly set and used? I would expect version to differ if the code has changed.

For me this issue is a fundamental/crucial part of app integrity. I am wondering why there is no official documentation on this (or why i am too stupid to find it 🤪).

Thx!

[markgreenwood]

I have a similar issue and captured these values to see if it might help resolve it. But I see two different versions reported... the server reports something like this: 6c2eaac7, while the client side reports this: 0.8293254086326534. I was expecting to see the same thing when I read @sergiodxa 's answer above:

Client-side, you can access this value window.__remixManifest.version to know the build version of your app, server-side this value is available in the build.assets.version in your HTTP server

Should I be seeing the same value for both?

[Annukul]

@markgreenwood Did you get it to work?

[patrick-mcdougle]

Just following up with competitive analysis. NextJS does this automatically because the build id changes and the routes and data 404 which triggers a hard reload of the app. IMO remix should do something similar to avoid this problem.