T
TanStack2mo ago
adverse-sapphire

Is there a way to `navigate` or go `back` when the next location matches the previous location?

Sometimes we want the next navigation to use back to clean up the history stack. The implementation we have is to track the last location with useLocation and intercept calls to navigate and use history.back instead but it requires: - interpolating the NavigateOptions like to, params, ... - tracking the last location with useLocation and an effect The above works but I'm wondering if we've missed something in the actual navigate api or a better way than tracking the last location with useLocation.
8 Replies
extended-salmon
extended-salmon2mo ago
do you have a complete example?
adverse-sapphire
adverse-sapphireOP2mo ago
yep. i tried to capture it in this gist https://gist.github.com/kevinehosford/30188b1952c7d326bef383c72cacb8ee so this is trying to show a pushOrGoBack scenario. here's posts.new.tsx and after creating the post the idea is to send the user to /posts but they might have come from the posts page with <Link to='/posts/new'> but also could have come from the home page with that link. if they came from the posts page - just call history.back() otherwise push the navigation. i also tried to explain what i meant with the to interpolation question
if (options?.to) {
nextHrefToUse = Object.keys(options.params ?? {}).reduce((pathname, key) => {
return pathname.replace(`$${key}`, options.params?.[key]);
}, options.to);
}
if (options?.to) {
nextHrefToUse = Object.keys(options.params ?? {}).reduce((pathname, key) => {
return pathname.replace(`$${key}`, options.params?.[key]);
}, options.to);
}
Gist
posts.new.tsx
GitHub Gist: instantly share code, notes, and snippets.
extended-salmon
extended-salmon2mo ago
just to understand this better, why does it matter where they come from?
adverse-sapphire
adverse-sapphireOP2mo ago
well for us it's because our app tries to avoid adding to the browser history sometimes so that using the back button doesn't replay modals or forms in this example if the user's journey was /home -> /posts -> /posts/new -> /posts, we'd try to use history.back() from /posts/new so that the next browser back button click would go from /posts -> /home instead of /posts -> /posts/new
extended-salmon
extended-salmon2mo ago
would just replace: true help here?
adverse-sapphire
adverse-sapphireOP2mo ago
i don't think it will because then the history would have two entries for /posts since the replace happens in /posts/new where the onSuccess handler is
rare-sapphire
rare-sapphire2mo ago
You could probably just make it such that the button or link that takes you from /home -> /posts also has a replace (or anything that goes to /posts) and then do the same thing going from /posts/ -> /posts/new. As long as you just keep replacing, then going back will go back to the last place you didn't replace the history state. If you don't want to include a modal or form in your state, whatever action takes you to that form can just have a replace on it to avoid pushing this to the state. I guess it depends how dynamic this situation is, but a push approach may be easier to accomplish than a pull approach, since replacing is quite trivial when pushing a route
extended-salmon
extended-salmon2mo ago

Did you find this page helpful?