fix: Await should fallback on route params navigations

[brophdawg11]

I was a bit naive in the "is revalidating" check to determine when to await all deferred values. We need to distinguish current loaderData for the same route and the same params versus same route but different params since we do want to fallback by default in the latter case (i.e., navigating /invoices/1 -> /invoices/2`).

Closes #8914

[changeset-bot]

🦋 Changeset detected

Latest commit: 1f9b461

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

This PR includes changesets to release 5 packages

Name	Type
@remix-run/router	Patch
react-router	Patch
react-router-dom	Patch
react-router-dom-v5-compat	Patch
react-router-native	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

[danillewin]

Hello @brophdawg11, hope you are doing well

I have a question: will this work if i change SearchParams, e.g. during pagination? /users?page=1 -> /users?page=2

In my case, it seems to be not working, unfortunately. I'm changing SearchParams using setSearchParams, and after it loader is fired, returning deferred object, but Suspense Fallback not Rendering(only renders on first load)

When I use route params for pagination - it works well: /users/1 -> /users/2.

I guess, from your commits, that the problem is isNewRouteInstance function:

return (
    // param change for this match, /users/123 -> /users/456
    currentMatch.pathname !== match.pathname ||
    // splat param changed, which is not present in match.path
    // e.g. /files/images/avatar.jpg -> files/finances.xls
    (currentMatch.route.path?.endsWith("*") &&
      currentMatch.params["*"] !== match.params["*"])
 );

There's a check for pathname matching, which will yield true if SearchParams have been changed (only my humble hypothesis)

I'm stuck for hours with this issue and will appreciate your help)