Reference of `router` returned from `useRouter` is not preserved about next-router-mock

[scottrippey]

I'm currently on vacation without access to my computer, so I won't be able to test this until next week. But I have some questions in the meantime.

How confident are you that in Next, the useRouter reference doesn't change?
I intentionally added the "change the reference" behavior, based on what I thought Next was doing. I even added unit tests for this scenario.
Maybe the behavior has changed between Next versions?

One big reason I ask is because router.query could change between renders, but if you used just router in your dependencies, it wouldn't trigger the dependency change. Maybe Next doesn't care, but I'm pretty sure that's how it worked when I was testing it last.
I could definitely be wrong, but I want to make sure.

[scottrippey]

I created a sandbox to test this issue: https://codesandbox.io/s/test-next-router-reference-lqbn0i
What I'm seeing: whenever I call router.push(...), the component re-renders, and the useRouter() hook returns a NEW reference each time the router.query changes. When non-route-related changes occur (eg. setState is called), the router reference doesn't change.

This is what next-router-mock accurately reproduces. So I think this behavior needs to stay as-is.

Please let me know if you can reproduce different behavior from Next, or perhaps if a different version of Next behaves differently. Thanks!

[raon0211]

Sorry for the late reply.

You are indeed correct; I think since the page component usually unmounts after invoking router.push or router.replace, we did not encounter the problem of infinite rendering.

It seems that having router.replace in the deps of useEffect (#37 (comment)) is not an option because it also runs into infinite rerendering (Codesandbox). Also ESLint warns about the incorrect deps problem (I remember this is due to the notorious this in JS).

It might be better for us to create a fake Next.js app which simply unmounts the component when router.pathname changes. I think this matches the actual behavior of Next.js.

Thanks for looking deeply into the problem and helping us 👍