Use one NavHost (with multiple navigation scaffolds) #101
Conversation
Previously, the app had a NavHost but didn't actually call navigate. NavHost's startDestination was read from external state (the currently selected nav item), which led to some undesirable behaviors. - NavHost itself was recomposed when selecting a nav item. - Pressing back always exited the app because you were always at the start destination. Now the NavHost has a stable startDestination, and nav item state is driven by the NavHostController's current destination. Selecting a nav item calls navigate, and the user always goes back through the startDestination before exiting the app.
| composable<Route.Settings> { | ||
| SocialiteNavSuite( | ||
| navController, | ||
| modifier = Modifier.sharedElement( |
There was a problem hiding this comment.
I think there's an interesting issue here when everything comes together with Modifier.sharedElement + NavigationSuiteScaffold inside a NavHost.
The Modifier here that is passed to SocialiteNavSuite ends up being applied to the navigation UI (as displayed by the NavigationSuiteScaffold) and all of the contained content.
We don't want all of the contained content to be part of the shared element - the only thing that should be shared is the navigation UI itself. I think we can accomplish that by using the NavigationSuiteScaffoldLayout @Composable and NavigationSuite instead, which allows us to set the shared element Modifier on the navigation UI itself.
| ksp = "2.0.0-1.0.21" | ||
| lifecycle = "2.8.4" | ||
| material3 = "1.2.1" | ||
| media3 = "1.4.1" | ||
| navigation = "2.7.7" | ||
| navigation = "2.8.0-rc01" |
There was a problem hiding this comment.
Nit: I think we can update to 2.8.1 now that it is out.
Consolidates all the navigation into one NavHost. A NavigationSuiteScaffold is inserted into each destination screen that wants to show navigation UI.
Fixes #96.