Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to go "back" for URL transitions #85

Open
jamesarosen opened this issue Mar 6, 2014 · 3 comments
Open

No way to go "back" for URL transitions #85

jamesarosen opened this issue Mar 6, 2014 · 3 comments

Comments

@jamesarosen
Copy link

A handler can abort a named transition as follows:

afterModel: function(foo, transition) {
  if (foo.isInvalid()) { transition.abort(); }
}

The router will not transition to the new route and will not call updateURL. All is good.

Unfortunately, for a URL transition, calling transition.abort() leaves the page in an inconsistent state. The router is acting because handleURL was called, which means the page is already at the new location (e.g. window.location.href has changed).

I'd really like some way of getting the page back to a consistent state. Some ideas:

  1. createURLTransition sets transition.previousURL and transition.abort() calls updateURL with previousURL if it's defined
  2. createURLTransition sets transition.previousURL, which afterModel can query and call updateURL as necessary
  3. createURLTransition sets transition.isURLTransition, which afterModel can use to conditionally call window.history.back() after calling transition.abort()
@sandstrom
Copy link
Contributor

sandstrom commented Nov 5, 2016

I'm doing some issues-gardening 🍀 🌷 and stumbled upon this. Is this still an issue? if not, perhaps it can be closed?

@nathanhammond
Copy link
Contributor

Considering the reporter (hi @jamesarosen!) I suspect that this likely was an issue. Given the report and my knowledge of how the sausage gets made This seems like it could reasonably still be an issue. However, it's entirely possible that @alexspeller's recent PR #197 addressed this.

Maybe someone can try to repro now?

@alexspeller
Copy link
Contributor

So I haven't looked into this in detail but I'd be extremely surprised if my changes made any difference to this particular case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants