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•2mo ago
do you have a complete example?
adverse-sapphireOP•2mo 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
extended-salmon•2mo ago
just to understand this better, why does it matter where they come from?
adverse-sapphireOP•2mo 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•2mo ago
would just
replace: true
help here?adverse-sapphireOP•2mo 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 israre-sapphire•2mo 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•2mo ago
probably this thread is of interest: https://discord.com/channels/719702312431386674/1392459528842379345/1392459528842379345