Hello! I already searched a lot about conditional `BottomNavigation` here but didn't found a solutio...

# compose

[Lucas Reis]

Hello! I already searched a lot about conditional BottomNavigation here but didn't found a solution for something I have in my project.

We created a AuthScreen in composable() that don't need to have a BottomNavigation and it's the first screen of the App. I have only one Scaffold for the app that encapsulates the NavHost.

I added a conditional logic on the BottomNavigation to only show when the current route is equal to some screens but not for the AuthScreen, similar to how this works on the compose samples.

Everything works fine, but I notice when the AuthScreen transitions to my HomeScreen (that is a route that has the BottomNavigation) the BottomNavigation appears before the AuthScreen fades away, and I found this behaviour a little strange, I think that it's something to do with the fade animation of navigation compose, anyone has this problem too and found a solution?

I tried putting Scaffold in all screens that has the BottomNavigation but I think this is not good, since Scaffold is better to be shared throughout the application.

[Ian Lake]

Navigation already has APIs for triggering your changes when the animation finishes / starts / etc., something we talked about on this Accompanist issue: https://github.com/google/accompanist/issues/633#issuecomment-942988181

[Lucas Reis]

I'll look into it, thank you so much!

[Lucas Reis]

It worked, thank you, I used visibleEntries to do this and animated accordingly

Only downside is that I need to put ExperimentalAnimationApi on annotation, this experimentals APIs just means that are things that can be changed? or are things that are not currently totally reliable?

[Ian Lake]

How AndroidX works is that when a library goes to beta, any non-experimental APIs are locked in stone, forever. It has nothing to do with how reliable or functional the APIs are

[Ian Lake]

So those APIs certainly might change, but they'd only change when you, as the app developer, specifically chose to upgrade what version of the library you were using

[Ian Lake]

It is perhaps a lot more important of a distinction if you were building a library you distribute to other developers that you want to ensure remains forward compatible with new versions of your dependencies

[Lucas Reis]

Ok @Ian Lake, thank you for your detailed explanation!