Currently the Link component of the gatsby-link package will check if the given target URL is internal and will print a warning when in development environment/mode, but the used regex doesn't handle anchors correctly resulting in (multiple) warnings being printed on each page change.
To prevent this console logging noise the regex can be extended to include the # character to handle anchors for valid internal links:
-/^\/(?!\/)/
+/^[/#](?!\/)/
import React from "react"
import { Link } from "gatsby"
const MyLink = props => <Link to="/#my-anchor" {...props}>My Anchor</Link>;
export default MyLink;
Given the example code above a warning message will be printed to the console:
External link ${to} was detected in a Link component. Use the Link component only for internal links. See: https://gatsby.app/internal-links
Using the improved regex will allow such links since they are valid internal links and a common use case.
Internal anchor links are a common use case (especially for Markdown/MDX).
Even when the Link component works as expected when used with an anchor link before such an improvement, the large amount of warnings in the console (in development mode) are noisy and could unsettle beginners/newcomers and might lead them to the decision that their code contains bugs/problems.
@arcticicestudio This makes sense. Thank you for reporting this and opening a PR as well!
Hiya!
This issue has gone quiet. Spooky quiet. 馃懟
We get a lot of issues, so we currently close issues after 30 days of inactivity. It鈥檚 been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
Thanks for being a part of the Gatsby community! 馃挭馃挏
Sorry for the delay, I'll try to submit a new PR this weekend that adds some documentation improvements.
Hey again!
It鈥檚 been 30 days since anything happened on this issue, so our friendly neighborhood robot (that鈥檚 me!) is going to close it.
Please keep in mind that I鈥檓 only a robot, so if I鈥檝e closed this issue in error, I鈥檓 HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.
Thanks again for being part of the Gatsby community!
I can tackle this one if still relevant.
By the way, what about nested links? Say, I have a blogpost at /blog/my-article/ - currently, the warning is triggered and calling it out as _external_ is kinda confusing since the page is generated by the Gatsby engine.
@Powell-v2 I'm back home this weekend so there might be some time to finally finish this, but feel free to go for it if you like to. Also I've got no problem with nested paths. Have you made sure to use the to prop for the Link component and not the href prop?
Yep, I鈥檓 pretty sure I鈥檓 using to prop.
Update on nested links - I wasn't actually using forward slash at the beginning when generating slugs programmatically via createFilePath and createNodeField. I had it specified like so:
createNodeField({
node,
name: `slug`,
value: `blog${slug}`,
})
Apologies for the confusion! However, warning shouldn't be generated in this case either as it works just fine. Maybe such scenario should be accounted for as well?
@arcticicestudio, I've been away whole weekend, didn't have an opportunity to update you. On a more general note, I was just probing if you hadn't entirely dropped the ball on this issue : )
How to handle this, for now, I am also getting the same error I fixed it almost everywhere in the site but I am stuck at slug URLs
Sorry for the long delay again :flushed:, the 350+ issues and PRs in my own projects take a lot of time, but I've decided to go through my Octobox today and resolving some long outstanding tickets.
@gopherine Like @DSchau correctly mentioned in my PR https://github.com/gatsbyjs/gatsby/pull/11646#pullrequestreview-201561087, the Gatsby Link component should only be used for internal links, but not anchors. To create a link to an element (id) within the same page a simple <a> should be used. Using a Gatsby Link would trigger data pre-fetching for a non-existent page which should be avoided.
I've checked the Gatsby Link documentations again and, next to the section about using Gatsby Link only for internal targets, there is a new section how to handle programmatic and in-app navigation (added in gatsbyjs/gatsby#11909). It makes use of the navigate function of the @reach/router package (used by Gatsby so it can be imported without even adding it as dependency) that allows to link to an internal element like a hash anchor: navigate('#some-link').
I guess both the comment in my PR as well as both sections in the Gatsby Link documentations are enough to inform developers about possible solutions:
:arrow_right: So in my opinion this issue can be closed.
what if i want to navigate from other page to nested routes like this <Link to='blogs/blog#how-to-tackle-issues'>View</Link>. this still gives me warning
Most helpful comment
Sorry for the long delay again :flushed:, the 350+ issues and PRs in my own projects take a lot of time, but I've decided to go through my Octobox today and resolving some long outstanding tickets.
@gopherine Like @DSchau correctly mentioned in my PR https://github.com/gatsbyjs/gatsby/pull/11646#pullrequestreview-201561087, the Gatsby
Linkcomponent should only be used for internal links, but not anchors. To create a link to an element (id) within the same page a simple<a>should be used. Using a GatsbyLinkwould trigger data pre-fetching for a non-existent page which should be avoided.I've checked the Gatsby Link documentations again and, next to the section about using Gatsby Link only for internal targets, there is a new section how to handle programmatic and in-app navigation (added in gatsbyjs/gatsby#11909). It makes use of the
navigatefunction of the@reach/routerpackage (used by Gatsby so it can be imported without even adding it as dependency) that allows to link to an internal element like a hash anchor:navigate('#some-link').I guess both the comment in my PR as well as both sections in the Gatsby Link documentations are enough to inform developers about possible solutions:
<Link>only for internal links!:arrow_right: So in my opinion this issue can be closed.