fix: reload page when routeModules doesn't contain module for current route

[n8agrin]

This can happen when entry.client.ts isn't fully loaded before a route change occurs.

The fix is to validate the route's module is loaded, and if not, simply reload the page. Credit to @brophdawg11 who suggested this approach here: #1757 (comment)

See #1757 for more info.

Closes: #1757

• Docs
• Tests

Testing Strategy:

• added a new test (included in this PR) named browser-entry-test.ts

[changeset-bot]

🦋 Changeset detected

Latest commit: 8c18d95

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 18 packages

Name	Type
@remix-run/react	Patch
@remix-run/testing	Patch
create-remix	Patch
remix	Patch
@remix-run/architect	Patch
@remix-run/cloudflare	Patch
@remix-run/cloudflare-pages	Patch
@remix-run/cloudflare-workers	Patch
@remix-run/css-bundle	Patch
@remix-run/deno	Patch
@remix-run/dev	Patch
@remix-run/eslint-config	Patch
@remix-run/express	Patch
@remix-run/netlify	Patch
@remix-run/node	Patch
@remix-run/serve	Patch
@remix-run/server-runtime	Patch
@remix-run/vercel	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[n8agrin]

@brophdawg11 This is the PR I referenced here #5166 (comment)

[brophdawg11]

Thanks for the PR @n8agrin - I pulled it down and did some testing - nice work getting an E2E test for this!

I made some minor alterations - let me know what you think:

• I moved the check up into the initialization block of RemixBrowser since we don't need it to run on all re-renders, just on the initial hydration render.
• I also changed the approach do to a simple URL comparison. The matches comparison worried me a bit since I think it could potentially put us into a loop if a match for the initial URL was invalid (somehow got deleted from a CDN maybe). If it had no chance to pass on the subsequent reload, we'd get into a reload loop I think?
  • Instead, now we're just SSR-ing the initial URL and comparing that against window.location. Then if we find a mismatch and reload, that should always break the loop.
• I also removed the return <div/> since I don't know that it was much better of a UX. In my testing I was still seeing a flash of the error - and I think that's fine in these small edge cases.

[lpsinger]

I noticed I was tagged to review this, but I'm not a Remix maintainer. Was this a mistake?

[brophdawg11]

@lpsinger I think that's only because of your comment above from last month

[n8agrin]

🙏 this lgtm! Thanks for taking a pass @brophdawg11

[github-actions]

🤖 Hello there,

We just published version v0.0.0-nightly-ad9adee-20230615 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version v0.0.0-nightly-12440f3-20230616 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version 1.18.0-pre.0 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version 1.18.0 which includes this pull request. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[yarbsemaj]

Hello @n8agrin, this PR is causing issue with CDNs. Our CDN is caching page html with query params on from tracking links (e.g.) Google. This is then been compared to the URL another user is visiting and viewing the cached versions of the page, when the mismatch occurs the page gets into an infinite reload loop. I can see this affecting many users who also use CDN's like this.