Deployment safety with React Router/Remix

[einarq]

This is the scenario.

• You use React.lazy to split routes
• Chunks/filenames change between deployments
• A user that is logged in has not yet navigated to route Y
• You deploy a new version of the app
• User tries to navigate, but it fails since the chunk serving route Y no longer exists on the server

There are of course various ways for dealing with this. Some prefer to keep several versions of bundles available on the server for a while, but that means you're being served an old version of the app until you for some reason reload the page.

Recently we started doing this:
https://www.codemzy.com/blog/fix-chunkloaderror-react

Basically it means wrapping React.lazy in a function that automatically reloads the page if a ChunkLoadError happens during navigation (with some safeguards in place to make sure the automatic reload doesnt go crazy).

I've been meaning to try out the "lazy" feature in React Router dataloaders based on this article from @brophdawg11, but that doesn't let me swap out React.lazy with an approach that will do the auto reload.
https://remix.run/blog/lazy-loading-routes

SvelteKit has something built in for this, perhaps Remix should consider something similar:
https://kit.svelte.dev/docs/configuration#version

There is also another thing to consider, which I imagine gets even more prevalent when using Server Actions and servering rendering more and more.
When you deploy a new version, the backend/server part is always updated immediately. The frontend/browser part however is "old" until the user reloads the page. Weird things can happen when the two are out of sync; assumptions can be wrong or expectations in code are maybe not met.

Some of our apps (the ones I've been able to convince that the issue is real...) are doing something like this:
https://twitter.com/cpojer/status/1730150524786540631?s=12&t=UrqzSyBbztjjBZxKEje7Ew
(send a http header on every response which contains the current app version on the server, and compare with the app version the browser has loaded).

There also is a discussion on the Vite issue tracker:
vitejs/vite#11804

Would imagine that this easily becomes a discussion about whether its a bundler concern, a meta-framework concern, or just something that user should deal with themselves? In either case it would perhaps be good to hear what the Remix/React Router team think of this.

[brophdawg11]

perhaps Remix should consider something similar

FWIW Remix does some basic handling of this scenario by forcing a hard reload which will get the latest app contents + asset references: https://github.com/remix-run/remix/blob/main/packages/remix-react/routeModules.ts#L188

One thing we've seen folks do is monkey-patch fetch to send the manifest version on each request and then compare than on the back end and send back a custom header to trigger a reload.

I think it's a concept that Remix could potentially consider in the future as a meta-framework. I don't think it's something that belongs in React Router though.

[brophdawg11]

route.lazy is evaluated as part of the navigation flow, not the render pass, so you can use https://reactrouter.com/en/main/hooks/use-navigation#navigationstate to show navigational pending states.

[einarq]

Hm, ok.

I have nested routes, and would like to only show a loader at the innermost location.
So that when navigating to, and lazyloading, route Parent > Child > Sub-Child, then the loader would only be shown where Sub-Child should be rendered.

Am I right in that you are proposing something like this?

{navigation.state === 'loading' ? : }

Do I then have to start checking route is being navigated to etc?

I'm probably missing something, but to me this seems a bit clunky, especially also when combining it with the Await component, for awaiting the incoming loader data.

Wouldnt it be better to be able to rely on Suspense for this?

[brophdawg11]

seems a bit clunky

Promises are clunky in React due to the lack of first class APIs to deal with them. The Suspense docs note as much:

Suspense-enabled data fetching without the use of an opinionated framework is not yet supported. The requirements for implementing a Suspense-enabled data source are unstable and undocumented. An official API for integrating data sources with Suspense will be released in a future version of React.

In RR we currently avoid exposing Promises for this reason. React is fixing this in React 19 with use so once that us released I expect we'll be open to exposing more Promises for raw consumption and integration with Suspense.

[einarq]

Ok, so until that lands it seems difficult to have fine-grained control over where to place loading indicators as a response to navigation/lazy routes.

Or is there an example of that you could point me to?

[brophdawg11]

useNavigation.state !== "idle"

If you need to scope it to certain navigations, you have access to the current location in useLocation and the pending location and submission info in useNavigation(). That should let you get as fine grained as you want I believe.

[einarq]

Ok, that could work. Although trapping the lazy-load with Suspense would have been a lot simpler, and idiomatic React perhaps. Something for the future maybe? Another thought I had (thanks for all the replies btw) about the "safe deployment" thing. The goal of the lazy import wrapper is to trap the chunk load error as "locally" as possible. Instead of a lazy import wrapper, would it make sense to instead use the Route.errorElement?

…

On Wed, Mar 13, 2024 at 3:55 PM Matt Brophy ***@***.***> wrote: useNavigation.state !== "idle" If you need to scope it to certain navigations, you have access to the current location in useLocation and the pending location and submission info in useNavigation(). That should let you get as fine grained as you want I believe. — Reply to this email directly, view it on GitHub <#11302 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABT6D7XJGI5M7ABOVNL5ZDYYBSHFAVCNFSM6AAAAABDZXWFFSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONZUGU2DE> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[brophdawg11]

yeah route.lazy errors should bubble to route error boundaries so that would work too if you didn't want to wrap each one and just a boundary at the top (you would need to re-throw it through any child route boundaries to ensure it makes it to the top)