I'm struggling with the use-case of configuring childs of a composable (`TopAppBar` ) conditionally...

# compose

[Christoph]

I'm struggling with the use-case of configuring childs of a composable (TopAppBar ) conditionally.
I want to set a navigationIcon depending on a condition. but doing

navigationIcon = {
            if (showBackArrow) {
                IconButton(onClick = onBackClick) {
                    Icon(Icons.Default.ArrowBack)
                }
            }
        }

this results in a "empty" composable set to the app bar and therefore the title is inset.
what's the best approach here?

[Zach Klippenstein (he/him) [MOD]]

Does this work?

navigationIcon = if (showBackArrow) {
    @Composable fun() {
      IconButton(onClick = onBackClick) {
        Icon(Icons.Default.ArrowBack)
      }
    }
  } else null

[Zach Klippenstein (he/him) [MOD]]

I’m guessing TopAppBar has some conditional logic around whether the navigationIcon function is null or not

[Christoph]

unfortunately that does not work

[Louis Pullen-Freilich [G]]

Yep, null disables the inset.

navigationIcon = if (showBackArrow) {
    @Composable {
      IconButton(onClick = onBackClick) {
        Icon(Icons.Default.ArrowBack)
      }
    }
  } else null

Should work? Maybe the fun() is tripping up the compiler

[Louis Pullen-Freilich [G]]

Or even:

navigationIcon = (@Composable {
    IconButton(onClick = onBackClick) {
        Icon(Icons.Default.ArrowBack)
    }
}).takeIf { showBackArrow }

should work

[Christoph]

thanks, the last one is working!

[Zach Klippenstein (he/him) [MOD]]

It would be cool if TopAppBar would handle an empty composable automatically. I think it would need to be refactored to use subcomposition to do that though, probably not worth the effort.

[Christoph]

i think "conditional" composing is a bigger topic that will pop up more often.
i wonder if there are plans in that direction

[Louis Pullen-Freilich [G]]

It would be cool if TopAppBar would handle an empty composable automatically.

We could currently do this but we don't want to introduce a kind of 'type system' into @Composable {} - components shouldn't care whether there are no layouts, one layout, or multiple layouts inside for behavior IMO. null does make this a bit less friendly to work with, but it's semantically meaningful and there's a well understand difference between a type and the nullable version of that type, along with understood behavior changes.

Maybe an explicit boolean parameter here might be better though, not sure.

[Christoph]

ok, thanks for explanation and quick help! 👍

[Zach Klippenstein (he/him) [MOD]]

Hm, I hadn’t been thinking of that as a type system. My thinking is that if a composable function doesn’t have any content (i.e. doesn’t emit any nodes), it shouldn’t have padding etc added to it since you know there will be nothing there. Of course, you could still use other techniques to make a composable have no visual output (force size to zero, render all content with zero alpha, etc).

Anyway, my LGAF is quite low on this, I agree it’s probably better overall to not try to handle this case specially.

[Louis Pullen-Freilich [G]]

My thinking is that if a composable function doesn’t have any content

The problem is that this is very hard to know when you are accepting a lambda that comes from another function that accepts a lambda, etc - which makes it quite hard to look at the code and understand the behavior. And as soon as you add some modifiers (maybe just some padding), this will appear to not be empty, so even if the 'content' is just an empty box with some padding suddenly the title will be inset - this is the sort of behavior I'd like to avoid