Next.js: Possible bug: <Link>'s with a href to a hash/external site on dynamic routed pages try to preload non existent pages

Created on 9 Jul 2019 · 8Comments · Source: vercel/next.js

Bug report

Describe the bug

<Link> components whose href points to a hash <Link href="#abc"> or external site <Link href="https://google.com/xyz"> on a dynamic routed page e.g ./pages/blog/[id].js generate a <link rel="preload" ...> to a non existent page. This doesn't happen on standard pages e.g ./pages/index.js.

This is not a bug if <Link>'s should not link to a hash or external site and can be closed.

Either way, users can check for hashes/external links before passing them. <Link> is obviously designed for client side navigation however this is more of a convenience thing for designing components that use <Link> who don't know ahead of time if the href will be an internal, hash or external link.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

Repo: https://github.com/delbaoliveira/next-bug-hash/blob/master/pages/blog/%5Bid%5D.js

Download and yarn install the above repo
Run yarn build and yarn start (preloading is a production feature)
Navigate to the dynamic blog page: /blog/123
Observe the last two <link rel="preload"> tags in <head> that point to /_next/static/.../pages/blog/123.js and /_next/static/.../pages/xyz.js. These cause two 404's in the console.

blog/123.js is caused by

<Link href="#abc">
  <a>Go to hash</a>
</Link>

xyz.js is caused by

<Link href="https://google.com/xyz">
  <a>Go to external site</a>
</Link>

Expected behavior

Next.js should not try to preload Link's that point to a hash or external site.

Screenshots

Screenshot 2019-07-09 at 13 05 13

System information

OS: macOS
Browser: chrome
Version of Next.js: 9.0.1-canary.0

needs investigation

Source

delbaoliveira

Most helpful comment

Hmm, a # probably isn't supported but I don't see why it couldn't be. Either way, we need to add console warnings for things that aren't supported as mentioned by @kachkaev.

Let's keep this open for now. 🙏

Timer on 9 Jul 2019

👍2

All 8 comments

I don't think external links should be used with the Link component which is why there's an error when trying to pre-render them.

jbsmith731 on 9 Jul 2019

👍1

Hey @delbaoliveira! <Link>s shouldn't be used with external pages -- but it's weird this only happens on a dynamic page. We'll investigate this more soon.

Timer on 9 Jul 2019

👍1

@Timer WDYT of showing a dev-only warning when Links’ href is external? Should be a useful feedback.

kachkaev on 9 Jul 2019

That option is definitely on the plate @kachkaev!

Timer on 9 Jul 2019

👍1

@jbsmith731 @Timer Fair enough re: external sites. What about <Link href="#x">?

Also correction: The external site 404 also happens on regular page. This can probably be closed.

delbaoliveira on 9 Jul 2019

👍1

Hmm, a # probably isn't supported but I don't see why it couldn't be. Either way, we need to add console warnings for things that aren't supported as mentioned by @kachkaev.

Let's keep this open for now. 🙏

Timer on 9 Jul 2019

👍2

Here's another odd behavior of <Link /> with dynamic routes, not really sure if related, but just in case it has a common root cause. Maybe useful for debugging.