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.

[pshrmn]

I think that there could be a temp fix in a minor release of React Router, but the best long term approach would be for history to handle this automatically (e.g. with a method that compares the new location with the current location to determine if it pushes/replaces).

[guidobouman]

You want to fix this in react-router, okay.

But is there maybe a path for other libraries that have have a concept of showing screens (like modals) to also integrate programatically with the same history stack that react-router uses?

Something along the lines of:

import { RouterAPI } from "react-router-dom";

// optional
const options = {
  replace: false,
  // ...
}

RouterAPI.go('...', options);
RouterAPI.link('...', options);
RouterAPI.navigate('...', options);
RouterAPI.emitLinkClick('...', options);
RouterAPI.immitateLinkClick('...', options);

[pshrmn]

@guidobouman React Router uses the history package for its navigation.

[guidobouman]

@pshrmn I know. I have built this functionality on top of history for previous projects. I have also been advocating the adoption of link in history for some years: remix-run/history#470 (comment). But that's going against @mjackson's philosophies for the package. If we can't convince him in three years time to put it inside history, then I'm willing to adjust my approaches to something that might actually get merged and still fix the scenario I'm trying to solve.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[guidobouman]

@mjackson If this is the tracking ticket for this feature I would like to prevent this from becoming stale. Any ETA on 5.2?

[TrevorSayre]

@guidobouman @mjackson maybe we could consider updating https://github.com/ReactTraining/react-router/blob/master/.github/stale.yml to include a label in the exemptLabels section such as roadmap. Issues that have been accepted as something to be worked on can be labeled as roadmap and will not be marked as stale (and possibly closed) unless the roadmap label is removed.

[cloudever]

I just use history.block API always following way:

function applyBrowserLocationBlocker(history: History) {
  let currentLocation = null

  history.block((location, action) => {
    const nextLocation = location.pathname + location.search

    if (action === 'PUSH') {
      if (currentLocation === nextLocation) {
        return false
      }
    }

    currentLocation = nextLocation
  })
}

[ghost]

I'm with @guidobouman I thought that was the intent of not completely owning the history responsibility, exposing historys state. I do agree that non-state changing reloads of the same page route should be consolidated if at all automatable, atleast with a flag to use replace for those that want their hands off the navigation completely. The logic could live safely in Link to verify before dispatching.

[ghost]

I want to be clear I am satisfied with this behavior and would prefer any changes to be behind a flag rather than having to lock at version, are there any others seeing the current behavior as a feature rather than a bug? This package was a life saver and it deserves appriciation. I love the conversations I see over here. Keep up the great work!