[Feature]: Have the possibility to know if there is a route before.

What is the new or updated feature that you are suggesting?

I suggest add a property or a method in useLocation() that should know about if there is a route before the actual route in my webpage.

Before v6.4.0 developers could know if there is a route before the actual with window.history.state.idx but in v6.4.0 this property isn't available.

Example: https://codesandbox.io/s/react-router-issue-9265-forked-h5s1yq

If you put react-router-dom 6.3.0 and you refresh the navigator of codesandbox you will see idx.
If you put react-router-dom 6.4.0 and you refresh the navigator of codesandbox you will see null.

Why should this feature be included?

I think that this is too useful to know when you can go back and not eject the user from your website if they just entered and click on a back button. If you know that the just entered on your page and you don't have a previous route you can go to a general route.

[timdorr]

Duplicate of #9273 (for the idx issue)

We cannot know about prior history, as this is a browser-level privacy and security issue.

Isn't about privacy and security issue... Can be done by saving the routes in a provider and you can know if there is more routes before

[gustavopch]

We cannot know about prior history, as this is a browser-level privacy and security issue.

We can, it's just a matter of using something like the old idx. It's not only very much possible, but essential for a decent UX.

Example: enter a tweet from a new tab, hit the back button in the header (not the browser's one), it will take you to the home page, you won't leave Twitter. They use history.back() when there's a previous Twitter entry in the history and history.replaceState() otherwise.

[jenseng]

What Twitter is doing is clever, but it's not foolproof. They're using sessionStorage to track the history in each page/tab (check out sessionStorage.getItem('RichHistory') in the JS console). So while that generally allows them to know about that tab's history and then act accordingly (even across full page refreshes!), it has some limitations:

1. Users can disable sessionStorage
2. Poorly written code in the same app could mess it up (e.g. sessionStorage.clear())
3. Your domain might have a ridiculous amount of other stuff in session/local storage and be at the limit
4. It can't know about history outside the app. For example, if you click here to compose a new tweet, and then hit the "X" in the modal, it goes to the Twitter home page and adds a history entry, rather than navigating back to this issue.

All that being said, it might still be worth exploring further for react-router. But it's important to really understand what's happening and what the edge cases are.

[gustavopch]

Yes, what's actually going to fix the problem is the Navigation API, but there's no sign that Safari wants to implement it AFAIK. I appreciate your comment pointing out possible issues, but:

1. Most users don't disable sessionStorage.
2. Just document it.
3. Just document it.
4. That's exactly the behavior that I want. When users click the close button, they expect the modal to close, not to leave the website.

Providing a decent UX for most users is better than a bad UX for all users.

Just adding idx again and letting we check for idx === 0 ourselves will already help. Even call it EXPERIMENTAL_idx or UNSTABLE_idx if needed so it can be done quickly.

[brophdawg11]

useLocation().key is always default on the first page in a session, so you should be able to use that to determine if prior pages exist

[gustavopch]

@brophdawg11 Thanks for the suggestion. Unfortunately, redirecting with <Navigate> changes the key from 'default' to a random string even when replace is enabled, so it's not as reliable as the former idx. 😕

[brophdawg11]

If you're redirecting then you have full control over the new location.state so you can set any location.state value you want - including one that's derived from the value of location.key before the <Navigate>: https://codesandbox.io/s/navigate-path-before-dvu0ed

[gustavopch]

@brophdawg11 Thanks, that will do it.

I hope by the previous comments the maintainers can understand how this behavior is essential for a decent UX and reopen this issue.

IMO, the ideal solution would be:

navigate(-1, { fallback: '/home' })

[brophdawg11]

It seems like you have enough available to do this in user-land at the moment, but feel free to open a Proposal and make the case for a new API. Popular proposals will be considered on Michael/Ryan's weekly reviews. Check out https://remix.run/blog/open-development for more info on the development process.

[gustavopch]

Thanks @brophdawg11, you've been very helpful, I'll send a proposal.

Edit: Sent #9922, please upvote if you find useful.

[gabrielperales]

@brophdawg11 Thanks for the suggestion. Unfortunately, redirecting with <Navigate> changes the key from 'default' to a random string even when replace is enabled, so it's not as reliable as the former idx. 😕

Maybe, what we have to do is that replace doesn't change the key to a random string when it is enabled 🤔 . This way we don't have to change the API and in theory, that was the expected behaviour.

[gustavopch]

@gabrielperales Why not change the API? Remix wants to make it easy to build a delightful UX. Adding a fallback option to navigate() is in line with that.