Unnecessary top-level render from the router

[gaearon]

Verify canary release

• I verified that the issue exists in Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:41 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T6000
Binaries:
  Node: 16.14.2
  npm: 8.5.0
  Yarn: 1.22.15
  pnpm: 6.11.0
Relevant packages:
  next: 12.1.7-canary.11
  react: 18.1.0
  react-dom: 18.1.0

What browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

Describe the Bug

If you have rewrites in next config:

module.exports = {
  async rewrites() {
    // ...

Then Next.js will cause a top-level re-render right after the initial navigation:

next.js/packages/next/client/index.tsx

Lines 118 to 121 in e57e275

	(location.search || process.env.__NEXT_HAS_REWRITES)))
	) {
	// update query on mount for exported pages
	router.replace(

This has negative performance implications (if you don't have a bunch of memos, it may render the entire app twice 🙃 ), and can lead to cascading updates in userland effects which in turn may cause Suspense boundaries to get dehydrated (#33861 (comment)).

Expected Behavior

I would not expect Next.js to call replaceState on every single initial navigation for every page if I have defined rewrites in my config. (I only used rewrites for the RSS feed.) It is not obvious that just having rewrites in the config degrades the perf of every page in the application. In either case, even if replaceState is called, I would not expect the router component to propagate a context update if nothing in the route context actually changed (the path is the same, etc).

To Reproduce

Here's the branch:

https://github.com/gaearon/sc-bug-repro/tree/render-twice

yarn, yarn build, yarn start.

Notice that in production the effect runs twice. However, it should run once because there is no reason for the second render in production. If you remove rewrites from the config, it will run once as expected.

[shuding]

Originally, we added that behavior in #24189 to support query parameters in rewrites:

{
  source: '/rewriting-to-auto-export',
  destination: '/auto-export/hello?rewrite=1',
},

...which is a valid use case. I’m wondering that if it makes sense to only trigger the router's subscription if the state doesn't change (with deep comparison):

next.js/packages/next/shared/lib/router/router.ts

Lines 1670 to 1682 in f9ed795

	private set(
	state: typeof this.state,
	data: PrivateRouteInfo,
	resetScroll: { x: number; y: number } | null
	): Promise<void> {
	this.state = state
	return this.sub(
	data,
	this.components['/_app'].Component as AppComponent,
	resetScroll
	)
	}

[gurkerl83]

This may not be directly related to rewrites, causing unnecessary re-renders at the top level, but for re-renders in general.

The linked issue describes the problem of changing the hash of a route, which per se should not result in a re-render of the entire app starting in _app. Indeed, it is a change made to the router context; it seems only a single property "asPath" changes. Re-render from the top is too expensive for inner page navigation, which should be as lightweight as possible.

Maybe the linked issue can also be addressed to solve the current problem.

#34729

[gaearon]

Since the hash is part of the router context I don’t think it could be updated independently. But the suggestion to do a comparison first makes sense to me.

[cramforce]

Reopening since the change was reverted.

[kuus]

hi, is there any update or ongoing/planned work on this?