If a transition to a particular state+params is pending, attempting to go to that state+params again should be a no-op #42
Comments
christopherthielen
added a commit
that referenced
this issue
Apr 20, 2017
Previously, any calls to state.go would supersede the running transition. If the user starts a transition, then immediately starts another identical transition, the new transition supersedes the old transition. Now, if the new transition is identical to the running transition, the new transition is ignored. Identical basically means: same destination state and parameter values. Closes #42
|
Great this has been solved, specifically for the new behavior of aborting a state change: "Now, aborted transitions do not trigger the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the current codebase, attempting to go to a state+params identical to your current state+params is a no-op. This is good and makes sense, since there's nothing meaningful to do to transition from your current state+params to your current state+params.
However if you attempt to go to a different state+params, such as by clicking on a
ui-sref, a transition is always created and ui-router starts resolving the necessary data. This causes a problem if the user tries to click the sameui-sreftwice or more - ui-router will queue up a bunch of identical transitions, waste time retrieving the same resolve data repeatedly, and take much longer to actually switch to the new state.A request to transition to a state should therefore be ignored if either the requested state is exactly the current state or it is exactly the destination state for the current transition.
The text was updated successfully, but these errors were encountered: