$stateChangeSuccess is fired before previous state $scope is destroyed in 0.2.16

[bighuggies]

This fiddle shows the difference in order of $destroy and $stateChangeSuccess between 0.2.15 and 0.2.16

https://jsfiddle.net/n3emkeo7/

This change broke our application, and I think it could be quite a significant breaking change.

My guess is that it's something to do with 1be1379 (unconfirmed).

Our use case:

We have a navigation control which listens for $stateChangeSuccess and subsequently updates the URL using $state.go.

In 0.2.15 this was fine if you navigated to a different page, the navigation control was destroyed before the $stateChangeSuccess event was fired, so the control would only redirect the user if they were navigating to a child state.

In 0.2.16 the $stateChangeSuccess event is fired before the control is destroyed, causing the user to be trapped on the page with the navigation control regardless of if they are trying to navigate away from the page.

[nateabele]

Yeah, destroying scopes is necessarily deferred by the $animate API, otherwise views behave unpredictably when transitioning out. Scope management is nondeterministic relative to transition events, which is why we never make any guarantees about ordering.

I'm not sure there's anything we can do here, but I'm open to suggestions...

[bighuggies]

I think a change in the order of events should be considered a breaking change and should be highlighted in the changelog. It's very easy to accidentally depend on the order of events without realising you're doing it. Highlighting it in the changelog will let people know to look out for cases where they do this.

Semantically I think it makes more sense for $destroy to trigger before $stateChangeSuccess. I have no idea how difficult that is to achieve so I don't expect the behaviour to revert. It's something of an edge case so unless a lot of people come forward with issues it's probably fine to leave it.

I'll look into writing a test to verify the order of events firing (if one doesn't exist already) so we know if it changes in the future.

[limax84]

+1
This change broke our applicationS as well. On state changes, new controllers are now instantiated BEFORE old ones are destroyed. Does anyone know if this behavior is intended to be or if it is a side effect of some other changes ?
We will have to stick with the 0.2.15 version... :(

[dsendner]

+1 we had the same issue as well as we were relying on the $destroy event to reset some services when the view change

[cappsool]

+1 same issue for us as well

[nateabele]

Hi guys, sorry for your trouble. Again, this was the result of a fix for people with animated view transitions, where controller scopes were getting destroyed too early, causing rendering issues during animation.

@christopherthielen I guess we could try to detect whether people are using animation and opt them into the old behavior...? :-/

+1 Change it back. :(

[tempoc]

This also introduces ambiguity in terms of the "current" state and its properties. We got a bug where params that used to be there at the time of navigation are no longer available.

I understand the need for the original fix, but this is definitely a breaking change.

[willhighland]

+1 we are also having issues because of this change

[nateabele]

@4Ants I don't think we can change it back, sorry.

I don't have time to look at it right now, but I'm open to suggestions on how we could improve it without reintroducing broken behavior.

[chevcast]

This change breaks our angular-spinners library which relied on the $destroy event to unregister any disposed spinner directives from our service. The spinner tracking service can only have one spinner with the same ID at a time so when views transition the previous spinner needs to be unregistered first so the new one can register its new scope with the spinner tracking service under the same ID.

If we can no longer depend on this $destroy event is there some other event or way to hook into this so the spinner directive's scope is properly unregistered before the new directive tries to register itself with the service?

Edit: We decided to change our behavior so that new spinners with the same name override old spinners registered with that name. It's not ideal but it's better than making all users of both angular-spinners and ui-router key a manual unregister call from $stateChangeStart.

This is a breaking change.
Can this be introduced in major version or applied only if animation is used?

[ggoodman]

I've also had my code broken but appreciate the work that went into the last releases. @nateabele and @christopherthielen do you have any suggestions on how we might refactor our code so that we are able to 'destroy before create'?

[christopherthielen]

To those affected by this:

The ui-router philosophy is that the state machine drives the application. The views are secondary things that happen in response to the state changing. They're somewhat non-deterministic (you could pop them in and out of existence with an ng-if, for instance). I consider the views almost as side effects.

See if you can refactor your code to use the state machine hooks and events instead (onExit, $stateChangeSuccess) to perform your exiting cleanup.

Otherwise:

for the time, please revert to 0.2.15; We'll try to come up with a solution and plan a 0.2.18 (le sigh...)

---

I'm open to suggestions on how we could improve it without reintroducing broken behavior.

I'll echo @nateabele 's sentiment. Let us know if you have any ideas. Consider the issue that this change was addressing: #1643 where the view being animated out had its scope destroyed, and thus the outgoing view was mangled.

Have a look at this code:
https://github.com/angular-ui/ui-router/blob/master/src/viewDirective.js#L135-L172
https://github.com/angular-ui/ui-router/blob/master/src/viewDirective.js#L192-L224

We could really use the help right now. There are a lot of proverbial balls in the air right now, and it's tough to keep up.