fix(gatsby-link): Adds the ability to not pass the pathPrefix on navigate

[Minivera]

Packages/files changed

This changes the gatsby-link package (Should I update the version anywhere?) and the files src/index.js and src/__tests__/index.test.js in that package.

Description

The automatically added pathPrefix to the to in the navigate function of the Link package makes it so that navigating to ids in a page is impossible without specifying the current page. For example, trying to do navigate('#some-id') would send you directly to the home page rather than add the hashtag to the URL. At this moment, the only way to fix this is by using the window.___navigate version.

Since this behavior is probably intended as the base behavior, this changes adds the ability to remove the pathPrefix rather than to add it, so keep backwards compatibility.

How to test

Someone who would like to navigate to the url something.com/page-1#some-id can now use navigate like this: navigate('#some-id', { withoutPrefix: true }). The newly added test should confirm this works.

[DSchau]

@Minivera few questions on this PR!

1. Why not just use a regular anchor tag?
2. If we do go this route (basically making Link more generally applicable), I think it's better to parse the to prop more intelligently, rather than exposing additional options.

Thoughts?

[Minivera]

1. Why not just use a regular anchor tag?

In my case, I ported an old parcel app to gatsby (A decision I do not regret!) and some of the navigation was done through handlers. For example, I have one menu that uses onClick handlers for the navigation and does some more actions before navigating. Some of my navigation behavior broke due to how navigation works here however.

2. If we do go this route (basically making Link more generally applicable), I think it's better to parse the to prop more intelligently, rather than exposing additional options.

I'd be more than happy to provide some URL processing to improve this very ugly solution! I might be wrong, but to my understanding, the reason to for the prefix is to prevent external urls right?

So I guess we would have three types of URL:

• Normal url where the prefix gets added (Like some-path)
• Url where the prefix is already there (Like /some-path)
• Urls that do not redirect, but instead adds to the query string or a hashtag (#some-id or ?test=test)

I suppose case 1 and 2 are already handled, so we need to make sure that withPrefix and normalizePath can process the third type. Do I have that right?

[DSchau]

@Minivera I appreciate this PR, but I think I'm going to recommend a different approach for your use case.

We internalize the @reach/router library for routing, programmatic navigation, etc. and we build on top of it to enable things like pre-fetching and other niceties that make navigation to internal pages and routes super speedy.

However - in the case of a hash link the niceties we add on top of this base library are overhead, and not really wanted.

For this use case I'd recommend just using the navigate method from @reach/router directly, like so:

import { navigate } from '@reach/router'

navigate('#some-hash'); // obviously triggered by some dynamic action, e.g. onClick

Will this work for you? If so--it might make sense to perhaps tweak our gatsby-link documentation to make it clear that it's only for internal page links, and for something like hash navigation a regular anchor tag or using @reach/router directly may make more sense! Any interest in doing so?

[DSchau]

Also here's an example

[Minivera]

I sure could, I even did before moving to window.___navigate, but I wanted to prevent having to push unnecessary dependencies to the user and I supposed gastby would support that use case (Though I guess it won't duplicate since it's already in gatsby?).

I'm too new to the gatsby world to say, but I feel like support for the hashlinks should be build-in the links and navigate function, since it is in reach 🤔. Hashlinks don't work that well in react usually (No auto scroll on refresh), but they work perfectly with gatsby thanks to SSR, so I'd love to help add support for routing with hashtags.

But I'll leave it to your judgment, I can make a docs PR to specify that hashlinks don't work and close this one if necessary. (Also maybe make an issue to discuss this further?)

[DSchau]

@Minivera re:

I sure could, I even did before moving to window.___navigate, but I wanted to prevent having to push unnecessary dependencies to the user and I supposed gastby would support that use case (Though I guess it won't duplicate since it's already in gatsby?).

Yeah - it'll be de-duped. We already depend on @reach/router for routing and other core utilities, so it's already being included.

I'm too new to the gatsby world to say, but I feel like support for the hashlinks should be build-in the links and navigate function, since it is in reach

Yeah - I see how we can improve this, for sure. But like I said, the Gatsby linking utility is designed for page and route linking (and includes optimizations and other functionality) for those use cases. Hash linking is not a supported use case for our Link component, unfortunately :/

So yeah--let's close this out (and thanks again!) and then feel free to open an issue or PR improved documentation so it's clearer what the expectations around using gatsby-link and linking utilities should be!

Thanks!

[acnebs]

@DSchau

I'm confused.

Are you saying that <Link to="/about#contact">Contact Us</Link> is not a valid use case?

[DSchau]

@acnebs I'm not saying that!

By hash-linking, I mean only hash linking. If you're using <Link to="#contact">Contact Us</Link> the link component is pure overhead and isn't providing any value. In that case where it's only a hash you would use a regular a tag.

I think the gatsby-link documentation helps with this.