question for those who are using one

NavHost

, one

Scaffold

and

BottomNavigation

at the root level, with many nested screens & Composables under that: is there a recommended way to show and hide the

BottomNavigation

? I have a nested

LazyColumn

which I’d like to use to trigger showing/hiding of that

BottomNavigation

when I scroll up/down. this is fairly simple when the

BottomNavigation

is “closer” to the Composable triggering it, but when it’s deeply nested I wonder what the best solution is? do I simply pass a lambda like

toggleBottomNavigationVisibility

all the way from the top level where the

Scaffold

is, through many Composables, down into my deeply nested one? this would work but I would like to know if there’s a better way and my brain isn’t seeing it 😄

https://issuetracker.google.com/issues/217465473#comment6 has some discussion around a similar problem. That one is specifically for a

PostionIndicator

for Compose for Wear, but the same principle applies, since you’re trying to have a top-level component (in this case, a

BottomNavigation

) be driven by state that is scoped to a specific destination (a

LazyColumn

at some nested route) The issue has the full details, but the summary is setting up a shared

ViewModel

. You can use get access to that

ViewModel

in two places: Outside the

NavHost

to drive the

BottomNavigation

visibility, and inside the

NavHost

for the specific destination.

great, that’s the exact kind of advice I was looking for, thanks Alex

Don't the docs for this talk about how this should be done via routes?

😮 really? Got a link @Colton Idle? Curious to see how that would work

oh yep, the docs example of routes usage is how the rest of my nav architecture is built, it was just the triggering of showing/hiding the bottom nav bar that I was curious about.. and even then, there's a few ways to do it that all work, but I was curious about the "right" way, since I believe some of my ideas were absolutely not right 😂

Right, you don’t have to go all the way to the shared

ViewModel

route if the behavior is based purely on which route you are on. If you want it to be based on some state local to the destination (that you want saved properly), that’s where it gets trickier.