Before releasing Beta 14, we took some time to gather feedback from the Ionic community about how navigation UI should behave: not just how it should be animated, but how everything comes together in an app. In Beta 14, we made some major changes to the navigation structure and elements that follow some already well-established patterns that can be found in apps across all platforms. We feel these updates will smooth the process of building UI navigation for your app.<\/p>\n
<\/p>\n
In Beta 14, we introduced a new navbar inheritance structure. Any collection of elements in In many cases, you\u2019ll want just one In the example below, we define a nav-bar, with a button on the right, and then make a view that has a button on the left. When that view renders, it will contain both buttons, so the view will inherit any button that is already in the nav-bar.<\/p>\n Your typical structure will be:<\/p>\n Before we released Beta 14, we revisited the way we felt navigation UI should behave. Components like our Let\u2019s look at our side-menus:<\/p>\n In that left side-menu, you probably have a list of links to other pages in your app, while in the side-menu-content, you\u2019d have a nav-view to render these pages. In Beta 14, those links in the side-menu now trigger a change in the navigation stack. The view gets treated as a navigation root and has animation only on the child views.<\/p>\n As a result, you may not be able to use side-menus haphazardly in any view. The use of a menu should be to create a base of navigation, through which views will transition. For a more contextual menu, developers should consider components like popover<\/a> or modal<\/a>.<\/p>\n In our navigation research, we discovered that existing native SDKs that have a similar side-menu component and navigation stack automatically hide the menu toggle (hamburger) icon-button icon on child pages; it\u2019s only visible on root level pages. We agree with this UX approach and have made it possible using In order to improve performance, we’ve improved Ionic’s ability to cache view elements and scope data. Once a controller is initialized, it may persist throughout the app\u2019s life; it\u2019s just hidden and removed from the watch cycle. Since we aren\u2019t rebuilding scope, we\u2019ve added events for which we should listen when entering the watch cycle again.<\/p>\n An example of using these events would be:<\/p>\n With these updates, Ionic now has a more complete structure for navigation and view management. Check out the docs for more information.<\/p>\n ionNavView<\/a><\/p>\n<ion-nav-buttons><\/code> or <ion-nav-title><\/code> will replace what\u2019s in the header by default or from the main top-level view (likely your index.html file).<\/p>\n<ion-nav-bar><\/code>, and then you\u2019ll add the appropriate buttons for that page to the page\u2019s template.<\/p>\n<!-- index.html -->\n<ion-nav-bar>\n <ion-nav-buttons side="secondary">\n <button class="button" ng-click="doSomething()">\n Add\n <\/button>\n <\/ion-nav-buttons>\n<\/ion-nav-bar>\n<ion-nav-view>\n<\/ion-nav-view>\n\n<!-- some view template -->\n<ion-view>\n <ion-nav-buttons side="primary">\n <button class="button" ng-click="doSomethingElse()">\n More\n <\/button>\n <\/ion-nav-buttons>\n <ion-content>\n Some super content here!\n <\/ion-content>\n<\/ion-view>\n<\/code><\/pre>\nNavigation base<\/h3>\n
ion-tab<\/code> and our ion-side-menus<\/code> now have a lot more purpose behind them. Like their native counterparts, these components have become a base for navigation.<\/p>\n <ion-side-menus enable-menu-with-back-views="false">\n\n <ion-side-menu-content>\n <ion-nav-bar class="bar-positive">\n <ion-nav-back-button>\n <\/ion-nav-back-button>\n <ion-nav-buttons side="left">\n <button class="button button-icon button-clear ion-navicon" menu-toggle="left">\n <\/button>\n <\/ion-nav-buttons>\n <\/ion-nav-bar>\n <ion-nav-view name="menuContent"><\/ion-nav-view>\n <\/ion-side-menu-content>\n\n <ion-side-menu side="left">\n <ion-content>\n <ul class="list">\n <a href="#\/event\/check-in" class="item" menu-close>Check-in<\/a>\n <a href="#\/event\/attendees" class="item" menu-close>Attendees<\/a>\n <\/ul>\n <\/ion-content>\n <\/ion-side-menu>\n\n <\/ion-side-menus>\n<\/code><\/pre>\nMenu Toggle Visibility<\/h3>\n
enable-menu-with-back-views="false"<\/code> on the <ion-side-menus><\/code> element. ionSideMenus Docs<\/a>.<\/p>\nView LifeCycle<\/h3>\n
\n\n
\n $ionicView.loaded<\/code><\/td>\nThe view has loaded. This event only happens once per view being created and added to the DOM. If a view leaves but
\nis cached, then this event will not fire again on a subsequent viewing. The loaded event is good place to put your setup
\ncode for the view; however, it is not the recommended event to listen to when a view becomes active.<\/td>\n<\/tr>\n\n $ionicView.enter<\/code><\/td>\nThe view has fully entered and is now the active view.
\nThis event will fire, whether it was the first load or a cached view.<\/td>\n<\/tr>\n\n $ionicView.leave<\/code><\/td>\nThe view has finished leaving and is no longer the
\nactive view. This event will fire, whether it is cached or destroyed.<\/td>\n<\/tr>\n\n $ionicView.beforeEnter<\/code><\/td>\nThe view is about to enter and become the active view.<\/td>\n<\/tr>\n \n $ionicView.beforeLeave<\/code><\/td>\nThe view is about to leave and no longer be the active view.<\/td>\n<\/tr>\n \n $ionicView.afterEnter<\/code><\/td>\nThe view has fully entered and is now the active view.<\/td>\n<\/tr>\n \n $ionicView.afterLeave<\/code><\/td>\nThe view has finished leaving and is no longer the active view.<\/td>\n<\/tr>\n \n $ionicView.unloaded<\/code><\/td>\nThe view’s controller has been destroyed, and its element has been
\nremoved from the DOM.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n$scope.$on('$ionicView.afterEnter', function(){\n \/\/ Any thing you can think of\n});\n<\/code><\/pre>\nParting Words<\/h3>\n