`router.push` should accept object as `href` (like `next/link`)

[stefanprobst]

Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/eloquent-sun-d4x59c

To Reproduce

1. open the codesandbox
2. go to app/page.tsx and see the error for router.push
3. also see that <Link> in app/page.tsx does accept an object as href
4. also check pages/test.tsx to see that router.push from next/router does

---

alternatively (from the auto-closed issue #59598):

1. open the typescript playground link
2. see that passing an object as href works for Link and next/router but not for router.push from next/navigation

Current vs. Expected behavior

currently, router.push (and router.replace) from next/navigation only accept a string as href.

it should also accept the same object shape as LinkProps["href"] from next/link.

also note that the pages router (next/router) does accept the object href.

Verify canary release

• [X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #38~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov  2 18:01:13 UTC 2
Binaries:
  Node: 20.10.0
  npm: 10.2.3
  Yarn: 1.22.19
  pnpm: 8.12.0
Relevant Packages:
  next: 14.0.4
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

App Router

Additional context

No response

[christianjuth]

I also found the inconsistency between Link href and the new router.push/replace to be confusing. Object support would be awesome!

[GabenGar]

That's because next/navigation and next/router are completely separate routers. The pages one works this way because it depends on pretty old URL parsing logic which predates URL interface, so asking for its support in the new router is basically asking for legacy behaviour (with all its footguns) ported into it.

[christianjuth]

@GabenGar I appreciate the insight here. Could you expand on your explanation a little? What footguns existed in the old next/router api that no longer exist in next/navigation? It's odd to me that it was decided to simplify next/navigation but not next/link(within app router). Wouldn't porting over the legacy (I guess it's not legacy?) API of next/link bring the same footguns next/navigation was trying to avoid? It's strange to me that the router needed to change but link didn't.

What is the plan with pages router over the next few years. Is it deprecated or is it just legacy APIs like next/rotuer that will be deprecated? Does this mean it's ok for me to use pages router as long as I use next/navigation and not next/router? Or should I avoid pages router altogether?

I wish the Next.js team would provide more clarity on the long term plan for the framework, what APIs we should prefer today, and the longterm plan for older parts of the framework (e.g. pages router).

[nextjs-bot]

This issue has been automatically marked as stale due to two years of inactivity. It will be closed in 7 days unless there’s further input. If you believe this issue is still relevant, please leave a comment or provide updated details. Thank you.

[nextjs-bot]

This issue has been automatically closed due to two years of inactivity. If you’re still experiencing a similar problem or have additional details to share, please open a new issue following our current issue template. Your updated report helps us investigate and address concerns more efficiently. Thank you for your understanding!

[github-actions[bot]]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.