The material3 guidelines suggest implementing a bo...

# compose

[Christopher Mederos]

The material3 guidelines suggest implementing a bottom navigation bar such that "Re-selecting the currently active destination resets the scroll position to the top of the page."

However, this seems like no easy feat with navigation-compose. The recommended nav structure is a top-level scaffold with the NavigationBar as the bottomBar and the NavigationHost as the content. I can't think of a good way for the onClick of the NavigationBarItem to communicate with the screen-level scaffold scroll positions.

Because it involves going both up and back down the state hierarchy, seems like a high-level stateholder and launched effect would be the only way. Any other ideas out there?

https://m3.material.io/components/navigation-bar/guidelines#d034f3cf-f81d-4484-9c3c-8f107aa5a021

kyki4raf-reselect-current-destination_3P.mp4

[Stylianos Gakis]

It is true it's not convenient to do with the current setup.
I don't know if this guidance has dropped yet anywhere in the docs, but the new guidance now that we got shared elements will be that the bottom bar should be part of that screen itself anyway, so you got full control in there to do something in-place, like scroll to the top for example.
And you rely on the bottom bar being a shared element so that if you happen to navigate to another tab which also has the bottom bar there it just stays in-place in the navigation.

[Stylianos Gakis]

https://kotlinlang.slack.com/archives/C04TPPEQKEJ/p1719984025304229?thread_ts=1719982161.255149&cid=C04TPPEQKEJ

[Christopher Mederos]

gotcha... haven't looked into shared elements yet! I suppose if they maintain the animations on the navbar while transitioning to other screens, then that could potentially replace the top-level scaffold w/ navhost 🤔

I've tested out this launchedEffect idea and it does work. I suppose the navbar is truly a top-level piece of UI so it makes sense that it would require some top-level state. Doesn't feel great adding clutter to state above the NavHost though

[Stylianos Gakis]

Yup. Hence the shared element approach will be much nicer. For now we gotta do something a bit more ugly unfortunately

[Colton Idle]

ooh this is an interesting use case that an "in screen" nav bar solves nicely. cool!