A modern programming language that makes developers happier.

kotlinlang

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?

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

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

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

Or even:

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

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.

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

&gt; 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.

ok, thanks for explanation and quick help! :+1:

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.

&gt; 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