Better handling of breaking changes in loader, for stale pages

[iamkd]

What version of Remix are you using?

1.15.0

Are all your remix dependencies & dev-dependencies using the same version?

• Yes

Steps to Reproduce

1. Create a route with a loader that returns data and use this data somewhere in the component. I used
   return { result: { text: "test" } };
2. Add a link that updates the query param to trigger the loader (e.g. <Link to="?testParam=true">Click me</Link>
3. Load the page either without LiveReload or by using a production build (npm run build && npm start) and keep it open.
4. Make some breaking changes to the loader data structure (I my case I replaced result with result2) and replace it in the JSX component as well.
5. Save changes / rebuild server.
6. Try clicking the link.
7. See the page crash.

Expected Behavior

The new build release should trigger a page refresh during navigation/submission to load the new Javascript code.

The users of our application often keep their tabs open for a long time. If a new release changes something in the loader structure of the route, the application will break for users who had this route cached/open before release.

This can be solved by the application developer (for example adding some kind of a token in each loader or implementing service worker/regular checks and forcing refresh on client). However, I think it can also be solved out of the box, as it affects even the most basic Remix app without any additional logic or dependencies. Putting some metadata like "loader hash" in loaders and routes could help trigger page reload when they don't match. I am not sure about actions though.

Actual Behavior

The page crashes because of the different data structure returned by the loader and the old client code being not aware of the changes.

[machour]

@iamkd I took the liberty of converting your issue to a proposal, so that it gets discussed by the community and make it under the team radar ✌️

This world definitely be a nice addition to the framework