https://kotlinlang.org logo
#compose
Title
# compose
c

Colton Idle

11/24/2021, 11:54 PM
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.
Copy code
@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?
z

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:
Copy code
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 🙂