Standard way of invalidating the client manifest after a new deploy

[rossipedia]

There's an issue has that seems to be cropping up after turning on Lazy Route Discovery which I outlined in Discord:

@rossipedia
so basically:

• deploy version 1
• user gets partial manifest
• deploy version 2
• user navigates to new route, requests manifest patches
• user now has partial version 1 manifest, partial version 2 manifest

I didn't quite make the connection, but it perfectly explains the mistmatched context issues that I and other seem to be seeing.

Basically, the issue is in this step:

• user navigates to new route, requests manifest patches

After a new deploy, it's entirely possible (and likely, even) that the entire chunking / code-splitting strategy has changed for the new set of static assets, resulting in React itself living in a new chunk.

When the patches get installed into the manifest, and the new module graph gets downloaded, you end up with two versions of React (and other things in your app that should be singletons now.. aren't).

This leads to a separate instance of React.createContext() being called, and since React context operates on referential identity, you end up with useContext() returning null when it shouldn't.

The "brute force" band-aid for this issue is to tell vite to use stable chunk names for your dependencies, but it doesn't solve the underlying issue, which is that there needs to be some way to:

• detect when a new version of the manifest exists in the server environment (ie: after a new build/deploy)
• "reset" the client-side manifest back to it's initial starting state as if it had been passed down during an SSR handoff, which would let lazy route discovery kick in as usual and populate the now empty manifest with updated and correct values for the current build.

[sergiodxa]

I think any navigation after a new deploy should cause a document request loading the new manifest again, so when RR loads a new manifest patch the server could include a header with the build version, if RR checks the build version is different it does a document reload.

[rossipedia]

I'm not so sure react-router itself should be in charge of document navigations like that. Since performing a full document navigation is potentially a destructive action, and react-router pulling the plug like that feels like it could be disruptive to the user experience, not to mention getting the timing right for when to force a whole document refresh feels tricky.

But then again, maybe that is the best way. The downside of just invalidating the manifest is that if you just reset the manifest and load an entirely new module graph, the browser itself is going to hold on to those original modules much longer than intended and over time you'd end up with users thinking your framework has a memory leak (which it would). Since ESM in the browser has no way of clearing the module cache (for good reason).

🤔

I think RR should do something to detect the condition where "server build and client build are out of sync", with the __manifest route being particularly sensitive to it and directly causing issues.

Stabilizing a vendor chunk across deploys would mitigate a lot of these issue, but not all. It would be especially trivial to repro it in a set of routes where a React Context instance is created at the module level.

Definitely a tricky issue and I'm curious what the team's thoughts are for potential solutions here.

[sergiodxa]

If you don't want to cause a document reload then you're basically adding HMR to production

If you don't want to do that too, then RR should let you know when the version changed so you can decide what to do with your app. But then I'm not sure how to block navigations.

I think the main complication is that the manifest is not static thing you can just keep in a CDN cache forever and let older versions of your frontend keep loading it, once the server is updated it will serve the new manifest always.

[dmarkow]

Had a similar issue with Remix, but definitely more prevalent after the upgrade to v7. We keep a websocket open to our API server and have our deploy script broadcast an "update available" message. Our custom Link component will do a full page reload when clicking a link if it gets one of those messages. It helped reduce the crashes, but it's still super fragile. It doesn't cover form actions, and even for links there are instances where the websocket disconnects/reconnects cause missing update messages.

An official approach from the RR team would definitely be helpful.

[videvide]

I think I'm experiencing a similar issue, but in the dev server environment.

When I start the dev server and visit a route that hasn’t been fetched yet, it crashes. After a hard refresh, it works again. This seems related to how the client handles updates when the manifest changes, similar to what's being discussed here.

I've had a hard time debugging this or getting suggested fixes to work—neither my attempt at the 'brute-force' approach mentioned in this discussion nor my attempt at applying this patch resolved it.

Could this be a similar issue where the dev server is serving an outdated manifest or causing inconsistencies in module resolution? I’d really appreciate any guidance.

Let me know if you need any details about my setup!