I m having a bit of analysis paralysis at the moment on how kotlinlang #compose

I'm having a bit of analysis paralysis at the moment on how to refactor a MyCompanyBottomBar into an isolated component. Code in thread, but mostly asking what you think the right refactor would be.

@Composable
fun MyCompanyBottomBar(
    navController: NavController,
    items: List<Screen>,
) {
  val navBackStackEntry by navController.currentBackStackEntryAsState()
  val currentDestination = navBackStackEntry?.destination

  AnimatedVisibility(
      currentDestination?.hierarchy?.any {
        it.route == Screen.List.route || it.route == Screen.Account.route
      } == true,
      enter =
          slideInVertically(
              initialOffsetY = { fullHeight: Int -> fullHeight }, animationSpec = tween(950)) +
              fadeIn(animationSpec = tween(950)),
      exit = fadeOut(animationSpec = tween(1150)),
  ) {
    BottomNavigation(
        backgroundColor = Color.Black,
        contentPadding =
            rememberInsetsPaddingValues(
                insets = LocalWindowInsets.current.navigationBars,
            ),

Right off the bat things that "worry" me: 1. navController being passed in 2. The concept of a

Screen

being passed in 3. The animatedVisibility could arguably live outside of this component and MyCompanyBottomBar could arguably start at the BottomNavigation composable 4. Is it fine to have LocalWindowInsets also defined in my reusable composable?

Zoltan Demant

11/25/2021, 10:14 AM

I would refactor out the design & animation to a component, then let something else (navController) control its behavior. In my project I went with the slot solution for the items:

crossinline content: @Composable NavigationBarScope.() -> Unit

NavigationBarScope then has

@Composable Item

which the caller uses to create the actual items. Personally I follow the rule that if a component should always perform an animation, Ill stick it in there; otherwise Ill let the caller do it instead! Hope this helps 🙂

#compose Join Slack