This feature could perform in two ways:
if the previous history entry is within the application's domain
go back to previous router history entry
else if the previous history is outside the application's domain
go back to fallback route
This would be beneficial for applications where the user can navigate to many different routes from a sidebar or topbar form of navigation, where the previous route could be one of many many different routes.
@jaredreich As far as I know, we cannot access actual history paths to check whether it is inside or outside the application's domain, for privacy reasons (enforced by the browsers).
Just imagine if it were possible: web apps that can access your history paths of current window.
So I'm closing this now, since this feature is impossible to implement.
This is actually possible to implement. Imagine this:
We keep a variable locationLast which get's assigned the router's location right before it traverses to a new route. Then when router.back('/fallback') is used, it checks if locationLast is assigned/defined, if so, this means the visitor has been to at least one route within our Vue app, so go back with history.back() style logic (to allow the user to go back to whatever route they just came from, without our Vue app having to know what that was), if not, that means this is the first route the user has visited since browsing outside of our Vue app, so since we don't have access to history paths (like you pointed out would be preposterous), we then just route to the /fallback route.
This method does in fact work, as it is a working feature of a small router library that I created for fun: https://jaredreich.com/projects/dowels.
Food for thought! (Please un-close!)
If I understand correctly, your example would only work if the user presses a button (that calls back('/fallback')) inside your app, and would't work if the user presses the browser's back button (There is no way to keep the user from leaving your app when he clicks browser back, without constantly pushing to window.history).
Then in this case, the app is actually managing a local state (whether or not the user visited, and the history inside the app), and use it to decide whether to use history.back(), or to go to /fallback.
This is actually not vue-router's responsibility, since vue-router's focus is to sync browser history state with the app's state. And this 'fallback' feature can be done using the existing Vue's apis (without too much problem since you've implemented something similar) :smile:
This does not work with the back button in the browser. However, it can be solved for programmatic route manipulation.
The way I understand it, these are the things we need:
hasLastPath variable in $router or wherever it fits. Set it to false on app initiationlastPath to that routeback(fallback) to $router, which first checks the hasLastPath variable. If it is true, then $router.go(-1), otherwise do $router.replace(fallback)$router.back() and fallback isn't setThe user would then simply use $router.back(fallback) instead of $router.go(-1). There could even be an option for each route to specify what the fallback should be, then calling $route.back() without any arguments would just use the specific route's default fallback.
Does that make sense?
Can this be reopened? I've found the same issue so would like a back() fallback too.
I agree, it should be the vue-router's responsibility to control the $router.go(-n) and and permit a fallback route. When developers use vue-router, it is rarely their intent to completely back out of the vue application using go(-n)
The router can keep and manage it's own history and even the final existing browser back button click can be controlled with window.onbeforeunload or beforeunload.
+1
+1
+1
+1
+1
+1
+1
+1
+1
+1
Most helpful comment
This is actually possible to implement. Imagine this:
We keep a variable
locationLastwhich get's assigned the router's location right before it traverses to a new route. Then whenrouter.back('/fallback')is used, it checks iflocationLastis assigned/defined, if so, this means the visitor has been to at least one route within our Vue app, so go back withhistory.back()style logic (to allow the user to go back to whatever route they just came from, without our Vue app having to know what that was), if not, that means this is the first route the user has visited since browsing outside of our Vue app, so since we don't have access to history paths (like you pointed out would be preposterous), we then just route to the/fallbackroute.This method does in fact work, as it is a working feature of a small router library that I created for fun: https://jaredreich.com/projects/dowels.
Food for thought! (Please un-close!)