[Multiplatform] Navigating away from TabNavigator screen

[justinrxu]

After an app user logs in, I have a main page of my app with Tab Navigation with separate Navigators in each Tab:

class MainView : Screen {
    ...
    @Composable
    override fun Content() {
        TabNavigator(
            object : Tab {
                ...
                @Composable
                override fun Content() {
                    Navigator(TabView())
                }
            }
        ...
        )
    }
}

I'm able to navigate within each tab. However, I would like one of my tabs to have a log out button, where I would navigate from that Tab inside MainView back to a login page. How would I achieve this?

[Syer10]

LocalNavigator.currentOrThrow.parent?.pop()

[Syer10]

LocalNavigator.currentOrThrow.parent?.parent?.pop()

[Syer10]

I think a recent release possibly added a Navigator.root() extension function that would grab the top-most navigator.
That may be what you want.

[Qw4z1]

I use Navigator.popUntilRoot() is what you want.

I have nested navigators for different stacks (BottomSheetModal, Tabs, inner tab stacks etc), so I use a composable function to easily access the correct Navigator. Then wherever I am I can just call `RootNavigator().popUntilRoot() to pop the correct navigator.

Although... Now that I think about it I could probably create an extension function on the Screen class to skip having to fetch RootNavigator first. =)

@Composable
fun RootNavigator(): Navigator {
    val current = LocalNavigator.currentOrThrow
    fun rootNavigator(navigator: Navigator): Navigator {
        return if (navigator.parent != null) {
            rootNavigator(navigator.parent!!)
        } else {
            return navigator
        }
    }
    return rootNavigator(current)
}

[KoTius]

I actually have the same question and the popUntilRoot() doesn't work.
The setup is:

• App() Navigator which initially loads MainScreen. Can load LoginScreen() in case of no Auth. And there are no more usages of it.
• Main screen hosts TabNavigator. Every Tab has it's own Navigator.
• Imagine we are on the first tab, which hosts navigator with ProfileScreen
• ProfileScreen requests logout -> We do App navigator.replace(LoginScreen()). Effectively that disposes MainScreen and MainScreenModel. But it doesn't dispose the ProfileScreen's model. And there are main issue for me.
• Then after login we do App Navigator.replace(MainScreen) - effectively disposing Login -> New Main Screen model initialized -> Old Profile Screen model returned, because it was never disposed -> Since it is still in the state "go logout" we are navigated to logout again, effectively in a loop.

I had popUntilRoot() when such logout happens, but I think it stopped working in latest versions (or never worked for me). I can't find a way to clearly get rid of everything hosted in MainScreen.

I played with the TabNavigator.disposeNestedNavigators = true in the Main. Sure, it fixes the loop, but I don't want that to be true forever, I need to clean the stack only one time.
Am I missing some simple Voyager concept which would help to resolve this?
@Syer10 Please help.

Logged that behavior, the issue is very clear for me, how to resolve - is not:

UPD:
I managed to hack it, basically with one line:
if (hasGrandparent) { navigator.replaceAll(EmptyScreen()) }

The idea is that if hasGrandparent (Current is the Navigator in a Tab, Parent will be TabNavigator and Grandparent will be the App Navigator). So if there are 3 levels we assume that we are in a Tab.
And the hack - navigator.replaceAll(EmptyScreen()) just replaces everything with the Empty dull Screen to force Screen models to dispose.

That is kinda stupid. And might not work if we add more navigators down the tree and the Logout will be triggered there. But it works :/

UPD2: Unfortunately this clears only the stack of the current tab and all other tabs view models are still in the memory.
And seems like we can't even access the siblings tabs graphs to clear them too.

[Qw4z1]

@KoTius, I think you're problem is slightly different. You're asking about ScreenModels being remembered for too long, right?

I would start by reading the docs on ScreenModels and then trying to use tags when calling rememberScreenModel, where CUSTOM_tag could be the user id or a random session token that you create or something.

val screenModel = rememberScreenModel(tag = "CUSTOM_TAG") { HomeScreenModel() }

You could also check if using a unique screenKey (again, probably user id or something like that) as described in the State Restoration docs.