Hi @Gajotres, I know what the order is (also mentioned in my first post and demo), and I know how it should work in theory. However the theory doesn’t match the practice. We can argue about the order – I think it should be beforeLeave -> beforeEnter – but I’d be okay with the current behavior if it worked as advertised.
Your blog post (and the documentation) claims that beforeLeave is triggered “when the view is about to leave and no longer be the active view”. So it is still the active view, right? Well no, that’s not what happens.
Take this example: http://codepen.io/anon/pen/NqBQJd
Click on the About tab. You’ll see an alert box with three different ways of trying to detect the active view. According to $ionicHistory, it’s already changed to tabs.about (beforeLeave!!) so that’s wrong. According to ion-view[nav-view=“active”], it’s still home (correct). And according to ion-nav-view[nav-view=“active”] it’s the about tab (also wrong if we follow the docs).
Now here’s where it becomes interesting. Click on home and about again. You’ll notice that when the about tab is cached, ion-nav-view active all of a sudden does become home. So the first time it’s wrong, the second time it’s correct.
Here’s another example of where it goes wrong, this time trying to cancel changing states. If beforeLeave worked correctly, and the active view would still be the one you’re about to leave, you could expect to easily cancel that process. Here’s an example, trying to cancel going to the about that from beforeLeave: http://codepen.io/anon/pen/pJOzNV
Well that did nothing (this bug has been reported). Okay, let’s try another way, using $stateChangeStart: http://codepen.io/anon/pen/OVoLWp
This did something. The about tab content does not get loaded, but about still becomes the active tab. This is the same discrepancy we saw before. Ion-view cancels correctly and keeps home as active, but ion-nav-view ignores this and changes the tab anyway. Again this would work differently if about was already cached. In that case, both home and about would be active.
Finally if you look at the actual code, you can see that in order to switch to a different view, you first need to register that view in history. Once you do that, the active view changes. Only afterwards do you start emitting leave events. If you want to do any cleanup that relies on the active view (like delegate handlers), or cancel changing views, you’re already too late.
As you can see from my examples, it’s not just one thing. It works fine on the surface, but if you try anything slightly more complex, there are simply too many edge cases, discrepancies between Ionic and AngularUI Router, and downright bugs. This is why I’m advocating for a second look at this functionality.