Suggest location: 'replace' on redirectTo behavior about core HOT 8 CLOSED

related: angular-ui/ui-router#3187 (comment)

Yes, I'd like to address this issue.

Note that we have to be smart about when to use/not use replace. We should only use replace if the router is responding to a browser url change. We should not use replace if the transition was initiated using $state.go() for instance. Here is why:

router responds to URL change

url changed to /A -> find ui-router state 'A' -> begin transition -> redirect to 'B' -> activate 'B' -> update URL with { location: 'replace' }

The URL changed to /A due to either a href link clicked or a sync during the initial application load (for example, user clicked a bookmark). Once we redirect to 'B', we don't want /A in the browser history, so replace is correct.

router initiates transition via $state.go()

browser url is /Z -> click ui-sref="A" -> $state.go('A') -> begin transition -> redirect to 'B' -> activate 'B' -> update URL without replace

The browser URL is only updated after a transition is successful. The url is never updated in response to the original transition to 'A'. After redirecting and activating B, we don't want to use replace because it would clobber the /Z in the browser history.

necessary changes

The code for this belongs in the redirect building code. Given an existing Transition (to 'A') that should be redirected and a new target ('B'), this code creates a new Transition to 'B' based on the original Transition.

This new Transition's options could be set to location: 'replace' if the original Transition's was started due to the url changing. I think checking for options().source === 'url' on the original Transition should be correct.

from core.

Ok I think I understand what you mean now with the concern on when to use location: 'replace', however I'm curious, for the explanation on router initiates transition via $state.go() are you saying that's the current behavior in the version 1.x code now, or the behavior you would like to see?

The reason I ask is because by the explanation:

The browser URL is only updated after a transition is successful. The url is never updated in response to the original transition to 'A'.

I should not need to click the back button twice right now when a redirect occurs since the url would never have been updated in the browser for transition 'A'.

Your necessary changes suggestion would only apply to the first scenario router responds to URL change correct?

from core.

for the explanation on router initiates transition via $state.go() are you saying that's the current behavior in the version 1.x code now

That's the current behavior, and also how it should remain.

I should not need to click the back button twice right now when a redirect occurs since the url would never have been updated in the browser for transition 'A'.

Correct. In the case of a redirect initiated during a $state.go() (for example, via ui-sref), the back button should work today. To see this in action, go here: http://plnkr.co/edit/qnsRwES54qgUW35wloal?p=preview Click other then click home -> redirects to home.foo. Click back button and you arrive back at /other

Your necessary changes suggestion would only apply to the first scenario router responds to URL change correct?

Correct.

from core.

After looking at my code, I think I know why I don't see the expected behavior you mentioned for $state.go, and it's that in some cases I am not using $state.go, and rather ng-href. I am guessing because the links are activated as regular URLs, then the url is not prevented from updating for transition 'A' before redirecting to transition 'B'.

So the next question is, would you consider non ui-sref and $state.go router changes (eg. links with ng-href or href) a "router responds to URL change"?

from core.

In fact after thinking about it some more, I would understand if you said links with href or ng-href behaved like "router responds to URL change".

The reason being it is out of the ui router influence, this means ui router would only be aware of the changes via a URL change. Thus, it would behave like:

url changed to /A -> find ui-router state 'A' -> begin transition -> redirect to 'B' -> activate 'B' -> update URL with { location: 'replace' }

Which then leads to the suggested change you requested for the code segment.
Hope I am on the right track

from core.

would you consider non ui-sref and $state.go router changes (eg. links with ng-href or href) a "router responds to URL change"?

Yes, anything which updated the URL (including href) is processed by angular which broadcasts the $locationChangeStart event. the ng1 adapter code listens for $locationChangeSuccess and then tells the urlRouter to update (check each URL rule against the current URL, and invoke the callback for the matched rule). When a state is matched, its rule calls $state.go(matchedstate, matchedparams, { source: 'url' }) and informs that the state change was triggered by a url change.

from core.

Hope I am on the right track

Exactly!

from core.

closed by 23e2b78

from core.