App uses nested NavHosts with unintuitive routing
- Dominant language
- Kotlin
- Stars
- 721
- Forks
- 162
- PR merge metrics
- No merged PRs in 30d
Description
This app has two `NavHost`s, one in [`Main.kt`][1] and another (nested) one in [`Home.kt`][2].
One peculiarity is the `chats` route (for the chat list) is in the nested `NavHost`, while the `chat/{chatId}` route is in the outer `NavHost`. It feels opposite from the expected, which is that `chats` should be a parent route for `chat/{chatId}`. Alternatively, to support large screens, there should be a destination capable of showing both `chats` and a selected `chat/{chatId}` destinations side by side.
Also, the nested `NavHost` isn't really used for navigation; there are no `navigate()` calls on its `NavHostController`. Instead, the current destination is external state that is read by `NavHost`, specifically to set [`startDestination`][3] to the route of the currently selected item in the nav bar. This has some undesirable effects:
- The `NavHost` recomposes entirely whenever the selected item changes.
- The `NavHost` is always on the start destination, so pressing back always exits completely instead of taking the user back to Chats first.
Ideally, the app should have one stable nav graph with all its destinations defined.
[1]: https://github.com/android/socialite/blob/85d11e853322b7afc0ca77ff2ac219389289d64f/app/src/main/java/com/google/android/samples/socialite/ui/Main.kt#L82
[2]: https://github.com/android/socialite/blob/85d11e853322b7afc0ca77ff2ac219389289d64f/app/src/main/java/com/google/android/samples/socialite/ui/home/Home.kt#L93
[3]: https://github.com/android/socialite/blob/85d11e853322b7afc0ca77ff2ac219389289d64f/app/src/main/java/com/google/android/samples/socialite/ui/home/Home.kt#L95
Contributor guide
Assessment
This issue has not been assessed yet.