Add prefetch to new router

[timneutkens]

Follow-up to #37551
Implements prefetching for the new router.

There are multiple behaviors related to prefetching so I've split them out for each case. The list below each case is what's prefetched:

Reference:

• Checkmark checked → it's implemented.
• RSC Payload → Rendered server components.
• Router state → Patch for the router history state.
• Preloads for client component entry → This will be handled in a follow-up PR.
• No loading.js static case → Will be handled in a follow-up PR.

---

• prefetch={true} (default, same as current router, links in viewport are prefetched)
  • Static all the way down the component tree
    • RSC payload
    • Router state
    • preloads for the client component entry
  • Not static all the way down the component tree
    • With loading.js
      • RSC payload up until the loading below the common layout
      • router state
      • preloads for the client component entry
    • No loading.js (This case can be static files to make sure it’s fast)
      • router state
      • preloads for the client component entry
• prefetch={false}
  • always do an optimistic navigation. We already have this implemented where it tries to figure out the router state based on the provided url. That result might be wrong but the router will automatically figure out that

---

In the first implementation there is a distinction between hard and soft navigation. With the addition of prefetching you no longer have to add a soft prop to next/link in order to leverage the soft case.

A heuristic has been added that automatically prefers soft navigation except when navigating between mismatching dynamic parameters.

An example:

• app/[userOrTeam]/dashboard/page.js and app/[userOrTeam]/dashboard/settings/page.js
  • /tim/dashboard → /tim/dashboard/settings = Soft navigation
  • /tim/dashboard → /vercel/dashboard = Hard navigation
  • /vercel/dashboard → /vercel/dashboard/settings = Soft navigation
  • /vercel/dashboard/settings -> /tim/dashboard = Hard navigation

---

While adding these new heuristics some of the tests started failing and I found some state bugs in router.reload() which have been fixed. An example being when you push to /dashboard while on / in the same transition it would navigate to /, it also wouldn't push a new history entry. Both of these cases are now fixed:

React.startTransition(() => {
  router.push('/dashboard')
  router.reload()
})

---

While debugging the various changes I ended up debugging and manually diffing the cache and router state quite often and was looking at a way to automate this. useReducer is quite similar to Redux so I was wondering if Redux Devtools could be used in order to debug the various actions as it has diffing built-in. It took a bit of time to figure out the connection mechanism but in the end I figured out how to connect useReducer, a new hook useReducerWithReduxDevtools has been added, we'll probably want to put this behind a compile-time flag when the new router is marked stable but until then it's useful to have it enabled by default (only when you have Redux Devtools installed ofcourse).

⚠️ Redux Devtools is only connected to take incoming actions / state. Time travel and other features are not supported because the state sent to the devtools is normalized to allow diffing the maps, you can't move backward based on that state so applying the state is not connected.

Example of the integration: