I’ve got some questions about the “historyRoot” in the $ionicHistory.nextViewOptions(). The description is “The next view should become the root view in its history stack.” But… what is the definition of “root view”? What does this imply? Any examples and explanations for this?
I’d probably ask best to the ionic team… Will try to tag some teammembers if no answers are given in a reasonable time periode 
The “root view” is what I’m calling the view which you entered the history stack at. For example, let’s say we have a side menu with two links in the left menu (View A and View B), and the initial view that loaded was View A. At View A, the menu icon shows in the header, and there’s no view to go back to, because it’s the first view.
From within View A, let’s say I click to go to View C. At View C, the menu icon should be hidden, the side menu should not be able to be opened, and the back arrow shows up which would link back to View A. This is all how native apps usually work and is our recommendation. At View C, we’re no longer at the root, but instead we’re one level into the history stack. If I were to click the back arrow, we’d be back to View A, and again at the root, which shows the menu icon again, and no back button.
So now let’s say I’m at View A, and want to go to View B which is another link in the left menu. Traditionally that would be navigating forward, and we’d then have a back button to go to View A and a menu icon, which isn’t a good UI. However, what we’re doing is saying that View B should still be considered the “root” of the side menus, even though View A was before it. But because we got to View B from the side menu, we want to View B to still have the menu icon, and not have a back button (because you can still get back to View A using the side menu).
Does this help explain it? Admittedly this is pretty confusing, but it’s commonly seen within native applications, and for good reason. But I’d like to improve our docs so it’s easier to understand, so any help explaining this would be appreciated. Thanks
If I understand correctly, following use case would be correct:
An application has a side menu from a home page, in the side menu there will be some options, a homepage, login, terms and conditions and a registering page. The side menu will be changed after login. After login, I would want to set the “after-login-home” as the new root, and thus “hiding” everything unauthenticated as the new root. Of course, terms&conditions, and newly (authenticated-only) pages will be still accessible, but since the after-login-homepage is the new root, navigation will be "intuitive and you will never be able to go back to login, registration and before-login-homepage (unless of course links are created from within authenticated-content)
Do I understand correctly?
PS: Docs on this subject could maybe be improved with some example-use cases instead of simply abstract explanation ^^
EDIT: after reading your answer again, your side-menu example A/B scenario is pretty clear… Maybe this could be hugely clear with putting a codepen together which both shows how it’s done and explains it on different pages… People could see it and read it at the same time ^^ I think it’s great now I understand how to use it 
Please still respond if my scenerio is correct as well