Use replace instead of push on <Link> click when location is the same

[jasonmacgowan]

Each time you click a <Link/>, it pushes to the browser history even if the location already matches. This differs from the default implementation of anchor tags as far as I can tell.

When a simple anchor tag is clicked 100 times, there is only one history entry
<a href="/foo">Go to Foo</a>

If you did the same for <Link />, you have 100 history entries which makes back and forward button navigation difficult.

Proposing we don't push when the location already matches

[mahesh-beehively]

Same issue react-router-native

[pnest]

Is it an issue? You can check link yorself and set appropriate 'replace' attribiute value in

[timdorr]

Edit: I have seen the abundance of thumbs downs and acknowledge my stupidity here. Feel free to ignore this comment...

@pnest has the right idea. This is "fixable" with the replace prop.

The point of <Link> is to emulate <a>. A normal <a> that links to the same page you are already on will push new history entities to the stack. For instance, click the react-router link at the top of the page a bunch of times. You'll see that you have to click back multiple times to get back to this page. We want to maintain HTML semantics with our defaults, rather than reinvent them.

[pshrmn]

@timdorr I actually think that the behavior of that link is caused by GitHub's SPA working incorrectly. Quoting myself from here:

From the WHATWG browser spec

If the navigation was initiated with a URL that equals the browsing context's active document's URL

1. Replace the current entry with a new entry representing the new resource and its Document object, related state, and the default scroll restoration mode of "auto".
2. Traverse the history to the new entry.

Where "equals" is defined here (basically, (a.pathname + a.search + a.hash) === (b.pathname + b.search + b.hash))

Using the replace prop can work, but I think that it would be better if history identified when navigating to the same location and replaces instead of pushes. That was the behavior in v2/3, but it was lost in the history rewrite.

Since this is a history issue, this doesn't need to be reopened. If/when history is updated to add same location detection, the <Link> API can be updated but for the time being replace is good enough.

[vladshcherbin]

@timdorr actually, normal same page <a> links don't create duplicates, so current <Link /> behavior is wrong and differs from 99% of websites. Even RR3 was working correctly, only RR4 is not.

@pnest this is a problem because it differs from default behavior, you have to reinvent Link component in every project because of RR4 (and history v4) bug.

This is a really annoying bug in RR4.

[mjackson]

Re-opening this issue because this is still broken. Going to add this to the roadmap for our next minor release.