We ran into this as well, when trying out the can.route.pushstate plugin. Our eventual solution was to basically remove all the intelligence from can route via a plugin (which I call "nullrouter"), because can.route's built-in intelligence relies on the idea that the url is *synchronized* with the observable/map attributes -- which is wonderful when manipulating the hash, but when you're working with the full url it results in extra history entries, difficulty recognizing unmatched routes, and the loss of 'forward' history after clicking the back button.
That "nullrouter" was a rather extreme solution, but it's been working very nicely for our app's needs. Here are some less-intrusive (and untested) ideas that might be worth trying out:
That "nullrouter" was a rather extreme solution, but it's been working very nicely for our app's needs. Here are some less-intrusive (and untested) ideas that might be worth trying out:
- Would it work to have the controller listen for "{can.route} change" and then manually check to see whether can.route.attr() is empty?
- If you're okay with using {route} events, you should be able to catch the empty with "/ {route}" -- I think this is what we're "supposed to" do, but I don't know if there's any way to avoid the additional back button history index.
- If you use "can.route('/', defaultParams);" outside of the controller to set a particular param, will the controller then let you listen to changes on that param? (I.e., something like "can.route('/', { emptyRoute: true });" and then listen for "{can.route} emptyRoute"?)