With Compose Navigation, let’s say you’re using BottomNavigation and you want a particular tab to remain selected as you navigate deeper.. I’ve seen something like this:

val selected = currentDestination
    ?.hierarchy
    ?.any { it.route == bottomNavItem.destination.route } == true

1. Is the idea that you have to leverage nested graphs in order for this to work? I’m sure this probably makes sense (because how else does Compose know that a particular destination belongs to the same hierarchy) So, assuming that is the case 2. If you have a screen that is accessible from two different Bottom Navigation roots.. You’d have to declare that route twice (once in each graph)? If that’s how it works, cool. Just want to make sure I’m thinking about this the right way

Regarding 2), yes, you probably want to declare two different routes. Tivi for example has a concept of "leaf screens" -- screens that can be accessed from more than one root. It basically allows you to create "dynamic" routes based on the root. https://github.com/chrisbanes/tivi/blob/main/app/src/main/java/app/tivi/AppNavigation.kt

Right, I see. I thought perhaps passing the root in as a parameter might be required. Thanks!

You can of course also declare everything statically, which might be more readable and easier to reason about.

I thought there was some way to leverage the

hierarchy

for this purpose, but I guess I don’t have a very good understanding of the compose navigation backstack

The hierarchy (the structure of your graph and how you nest graphs) is a completely separate concept from the back stack (the runtime set of screens you've gone through). You certainly don't have to use the hierarchy for your selected tab - it would be just as viable to just track the last tapped tab and use that as your source of truth for which tab is selected

Thanks for the clarification Ian. I ended up doing the same as Tivi does - appending a ‘root’ to the navigation route where required, and using that as the ‘source of truth’