Fall back to push/replace behavior when navigate(-1) would leave the website

[gustavopch]

First demonstration:

1. Enter https://twitter.com.
2. In the search input, search for Remix and navigate to its page.
3. Click the back button in the header of the page.
4. Twitter will call window.back().

Second demonstration:

1. Enter https://twitter.com/remix_run directly.
2. Click the back button in the header of the page.
3. Instead of calling window.back() (which would make you leave Twitter), a new history entry will be pushed.

I believe React Router should support the same behavior. It's terrible UX to press the back button (or even worse, a close button in a route-based form like https://twitter.com/compose/tweet) and end up leaving the website.

So I propose that the following code is supported:

navigate(-1, {
  fallback: '/home' // If going back would leave the website, navigate to /home instead
})

First, React Router must track the index of each history entry (as already happened before v6.4). Whenever a new history entry is pushed, set its state to contain idx: prevIdx + 1. When the current history entry is replaced, keep the same idx. Then, in navigate, just check:

const canGoBack = window.history.state.idx + delta >= 0

if (canGoBack) {
  window.history.go(delta)
} else {
  if (replace) {
    window.history.replaceState(...)
  } else {
    window.history.pushState(...)
  }
}

It's a low-hanging fruit that will enable a much better UX for apps using React Router. In the future, we'll be able to do window.navigation.canGoBack with the Navigation API, but support is narrow today, so we have to work with what we have.

Related issue: #9301

[ryanflorence]

Yeah that sounds reasonable. I usually do it in the app by checking if the location key is "default" though. Maybe we just need to document this UX edge case better?

<div>
  {location.key !== "default" && (
    <button onClick={() => navigate(-1)}>Back</button>
  )}
</div>

[gustavopch]

The "default" thing was mentioned in #9301 (comment), but it's not enough. When you have a route-based modal, you must show a close button even when location.key === 'default' (like Twitter does when you enter https://twitter.com/compose/tweet). If you want to provide the best UX, the back/close button must always exist, not only when location.key !== 'default'. So the button must always be there, and we have only to change its behavior: if the previous history entry is owned by our website, we can safely go back, otherwise, we have to navigate (by either pushing or replacing) to a fallback route.

Here's how we could naively try to do it:

<button
  onClick={() => {
    if (location.key === 'default') {
      navigate(fallback, { replace: true })
    } else {
      navigate(-1)
    }
  }}>
  Back
</button>

But:

First case

• Suppose you had a route-based modal at /modify, but then you decided to use /edit instead, so you set up a redirect <Route path="/modify" element={<Navigate to="/edit" replace />} /> to prevent breaking existing links.
• You enter /modify and it will internally call navigate('/edit', { replace: true }) (note that at this moment, key is changed from "default" to something else).
• Now, if you press the close button on the modal, you'll leave the website instead of just closing the modal.

Second case

• Suppose you have the following routes:
  • /companies
  • /companies/123
  • /companies/123/employees
• You enter /companies/123/employees.
• You press the header's back button. It checks if key === 'default', and it's true, so navigate('/company/123', { replace: true }) is called to prevent leaving the website (note that at this moment, key is changed from "default" to something else).
• Now, if you press the header's back button again, you expected to end up at /companies, but you'll leave the website instead.

---

I believe the navigate(-1, { fallback: '/fallback' }) idea that I described in the proposal is the best (possibly the only) way to address all of this, both from a UX perspective as from a DX perspective.

[gabrielperales]

We are facing the same issue, and by now, we are checking window.history.state.idx because it came back in version 6.7, but we have to lock this version just in case it goes away again 😅 .

Our case is similar to the one you described, our react app is running in an iframe and when there isn't a navigation stack we should close the iframe, otherwise, we have to go back.

[jiad-saegus]

i wrote this custom hook for react-router-dom 6.20.1

export const useGoBack = () => {
  const location = useLocation();
  const navigate = useNavigate();
  const thereIsAPrevPage = location.key !== "default";
  if (thereIsAPrevPage) {
    return (_arg: { fallback?: string }) => navigate(-1);
  } else {
    return ({ fallback }: { fallback?: string }) => navigate(fallback || "/");
  }
}; 

// usage
const goBack = useGoBack()
// example with default fallback
onClick={() => goBack({})}
// example with custom fallback
onClick={() => goBack({fallBack: "/hello"})}

[KutnerUri]

I'd expect some count to know how much we can go back / forward, like:

const [historyLength, futureLength] = useHistory();

// maybe
const navHistory: { prev: Location[], next: Location[] } = useNavigationHistory();
// or
const { back, forward }:  { back: Location[], forward: Location[] }  = useLocation();

then if (prev.length < 1) go to homepage, otherwise navigate(-1)

another option would be to pass a function to the navigate, like so:

navigate(({back, forward}) => back ? -1 : '/')

the browser history api only provides .go(), and not history state, to prevent sites from spying on users, but within React Router which is single site specific, it makes sense

[KutnerUri]

actually, when I think of it, it seems ideal to add back: Location[], forward: Location[] to useLocation(), and just allow callback to navigate():

navigate(({back}: UsedLocation) => back ? -1 : "/")

// or as second param if you don't want to add it to useLocation:
navigate((_, { back }) => back ? -1 : "/");