Notify: false prevents state transition entirely (not just events)

[homerjam]

Hi,

I've created a Plunker here

As shown in the example I think one would expect to be able to use event.preventDefault() in the $stateChangeStart event to prevent a transition, then later trigger that same transition manually with {notify: false} to prevent the event being triggered and therefore the state transition being blocked again (infinite loop).

However the viewDirective is relying on $stateChangeSuccess internally which is also prevented by {notify: false}.

One work around is like so:

$state.go(toState.name, toParams, {notify: false}).then(function() {
    $rootScope.$broadcast('$stateChangeSuccess', toState, toParams, fromState, fromParams);
});

I think perhaps the best solution here would be to use an alternative event internally to trigger the updateView() in viewDirective, or alternatively extend notify to target start/success events separately.

Thanks

[gfreeau]

+1 There are many open issues like this regarding $stateChangeStart and preventDefault. It's a common use case to run some kind of logic before state changes such as for authentication and authorization.

There isn't currently a good way to do this as the state change happens before resolves as well.

As an example, in my application, when the user logs in, their json web token is saved to local storage. When they visit the application again, that token must be used to check if it's still valid and then get the current user permissions from the server. This needs to happen before states should be initializing.

I was able to achieve this in the $stateChangeStart event, using event.preventDefault and a promise from my auth service and your workaround of broadcasting the $stateChangeSuccess event manually. If you don't do this, an infinite loop happens.

This same issue is being discussed in other issues such as #898.

People are also trying to achieve the same outcome in other ways, such as through a global angular resolve that happens before states try to initialize, such as in #946.

See also #1139, #618, #178 and #401.

[ProLoser]

Why is an app-level resolve not acceptable? The only thing I can imagine being an inconvenience is sending the user back somewhere if the resolve fails vs avoiding the entire resolution process entirely, but then this creates 2 separate places where we're doing querying for data we may want to use (such as if the current user is logged in). My vote is just to use a top-level resolve and close this issue.

[gfreeau]

@ProLoser, this can indeed be solved with app level resolves. In my application I ended up using the angular deferred bootstrap and removed my $startChangeStart listener.

The only downside is that you cannot use promises on every request, you can only do your authentication promises on the first load. So if you wanted to check Authentication on every request or requests after the initial load, you have to rely on the data you retrieved on app load, instead of the data at the time of the transition.

[christopherthielen]

Promises per transition is coming soon

[charandas]

👍

[leonpapazianis]

Hi guys,

Anybody knows if this bug is actually resolved? Is the $stateChangeCancel event helping on that? I am trying to find any relevant documentation on the new releases (0.2.15) but I cant really pinpoint an actual solution. @christopherthielen Chris is the promise based transitions still in the roadmap?

Regards..

[tihomir-kit]

Hi,

I would also like to know what would be a workaround for this.

Cheers

[christopherthielen]

@pootzko that depends on what you're trying to do (assuming with notify: false). In @homerjam's example, I think managing the infinite loop using a separate variable like retryInProgress would work.

$on("$stateChangeStart", event, to, toParams) {
  if (to.retryInProgress) {
    to.retryInProgress = false;
    return;
  }
  // do  stuff
  event.preventDefault();
  to.retryInProgress = true;
  $state.go(to, toParams);
}

@leonpapazianis yes, it is on the roadmap. You can use the proof-of-concept I added to ui-router-extras for now. See #1257 for details. I think code like this should work:

$on("$stateChangeStart", event, to, toParams) {
  // UI-Router Extras decorates the injector so you can do this in a event handler... 
  // UI-Router 1.0 will only allow $transition$ injection in places where resolves are normally injected.
  var t = $injector.get("$transition$"); 
  t.promise.then(transitionSuccessFn);
}

[tihomir-kit]

Thank you for the very prompt reply :)

Your first example helped me solve my issue.