Hello Ionic Community,
I have been looking everywhere, fruitlessly so, for a way to observe the navigation events and return the name of the destination view before the current view is unloaded. An equivalent of ionic1’s “$stateChangeStart” if you will, where we get the event, the toSate and fromtState, all before the event is propagated.
Currently, I am subscribing to viewWillLeave to ascertain the navigation behavior of the app. The problem I’m facing is that this subscription only returns the data pertaining to the current view. Is there a way to also get the data pertaining to the view that we are navigating to without the current view unloading or the next view starting to load?
As for the why: I would like to base the boolean of ionViewCanLeave on the destination view rather than on anything else. I know this might not be the best practice, but the company I work for is rather adamant on the user not being able to leave a particular view unless they are navigating to a particular set of pages. And so, knowing the destination view before the current view unloads is somewhat of a necessity.
Thanks in advance for any help that comes this way.
If you don’t get any better answers, here’s how I think of this. Every navigation action requires the user interact with some app element - a button, a menu item, or whatnot. Disable those when they should not be available, instead of relying on lifecycle events.
Thank you for the reply. This was my line of thought as well, which led me to opening this thread.
To know when the navigational elements must be disabled, we must first know which view we are headed to. For example: I navigate to page B from page A. Now from page B, the only place I should be going to, is page C. If I click on the browser back button, nothing must happen. Only if I click on the button that takes me to page C should the navigation work.
Knowing where we are headed seems to be impossible with the currently available lifecycle events without first unloading the current view.This has been one of the main reasons why my company is reluctant to the idea of migrating to ionic 2+. All the pros of keeping up with the updated framework seems to be overshadowed by the lack of required functionality, which is readily available in our app that is still stuck with ionic 1.
I’m not entirely sure if our requirement is considered to be bad practice, but I would think that basic information about navigational events isn’t something that should be so hard to get.
I don’t purport to be an arbiter of what constitutes good or bad practice; I can just speak for myself. What I would tell your client is this:
The more independent and self-contained we can make each component of our app, we will reap several benefits. It becomes easier to read, maintain, and test, because it is clear who is in charge of what. It is easier to modify, because we don’t have to worry about changes to part A accidentally messing something up in part B.
Users appreciate apps that guide them, but do not appreciate having core functionality hijacked. In the end, they want to feel like they are using the app, not the other way around. So I consider the browser back button sacred ground. It should always go back. Disabling buttons inside the app: absolutely no problem. Disabling the browser back button: user will hate me.
If you’re trying to implement some sort of wizard, where screens must be gone through in a particular linear fashion, the way I would go about that is using modals.
A bit of a ‘sidenote’ for the OP - if you are indeed implementing a wizard, do consider existing libraries for it. I’ve very successfully used angular-wizard for a v1 project that makes conditional navigation control much easier. There is an angular2 library too ,which I haven’t used, but looks very similar.
Thank you for the suggestions. This is not a wizard. It’s just a way to stop pages from making unnecessary API calls because of redundant navigation events. The nav guard ionViewCanEnter only works after the current page has loaded and the nav guard ionViewCanLeave is useless in this use case since we don’t know the destination. Going from an authenticated page which has a pretty heavy API call, to an unauthenticated page like login or register, and then being redirected right back to the very same authenticated page with the heavy API call using ionViewCanEnter’s promise, just seems rather superfluous to me.
I was hoping to find an event like ionic1’s stateChangeStart, which we could watch to get the destination views name and use that in conjunction with the ionViewCanLeave nav guard to prevent the page from having to go back to a page that is no longer of any use to us.
But it would appear that getting the name of the destination view from lifecycle events without unloading the current view is impossible with ionic 2+. Thank you guys for all your help, but it looks like we have no choice but to stick with ionic1 for now.