If you use a TopAppBar, do you think there should: a) be a separate instance of the top app bar asso...

# compose

[Tim Malseed]

If you use a TopAppBar, do you think there should:
a) be a separate instance of the top app bar associated with each screen, so that the screen owns the logic for populating the bar and handling actions that are relevant to that screen? Or
b) should the top app bar sit at the root level, and be shared between screens

[Tim Malseed]

With (a) you recompose the top bar on every screen, whether its contents change or not (and so you see the transition when changing screens). Probably can be fixed with some sort of custom transition.

With (b) you have to hold some kind of toolbar state that responds to events about which screen you're on, and which actions are possible, and passes down state about which action has been selected. This toolbar state ends up having to know about a lot of screen specific stuff (I think)

[Tim Malseed]

Hmm. I think (a) is the obvious choice

[Ian Lake]

We've talked about this previously, here's one such example: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1620959319009300?thread_ts=1620952017.004700&cid=CJLTWPH7S

[Ian Lake]

There's also this one: https://kotlinlang.slack.com/archives/CJLTWPH7S/p1602519668357600?thread_ts=1602214739.224900&cid=CJLTWPH7S

[Tim Malseed]

Thanks, I'll have a read

[Orhan Tozan]

@Tim Malseed With (a), the top bar wouldn't be recomposed on every screen if the content of the top bar stayed the same, right?

[Tim Malseed]

If the top bar is part of your screen composition, then yes - it's recomposed whenever you transition between screens

[Orhan Tozan]

Why? Let's say you have the following:

@Composable
fun Foo() {
    val myFlagState = ...
    when (myFlagState) {
        false -> {
             Text("Hi")
             Text("1")
        }
       true -> {
             Text("Hi")
             Text("2")
        }
    }
}

Sure when myFlagState changes, Text("Hi"), wont be composed since it stays the same, right?

[Orhan Tozan]

Otherwise Compose isn't that performant as I thought...

[Tim Malseed]

I think in your example, you're correct. I'm not sure if this holds when navigating between screens (via compose navigation, for example)

[Tim Malseed]

It might just be an effect of the transition - but when I host my TopAppBar in two different screens, I can actually see the transition from one TopAppBar to the next

[Orhan Tozan]

I don't know how the Compose Navigation library is implemented, but I assume it's just a big when statement

[Tim Malseed]

Yeah. I mean, I think that what you're saying is correct. I think the composition avoidance thing is smart enough to see that the structure of the two screens is the same, and so the top bar doesn't need recomposition. But since I can actually see some kind of transition, I'm not sure what's causing that or how to avoid it.

[Orhan Tozan]

Do you mean you see a transition in that there is an animation?

[Tim Malseed]

Yeah. You can see the top bar crossfade. The bars on both screens have a green background. You can see it crossfade green-white-green when you change screens.

[Tim Malseed]

It's worth mentioning that the contents of these two top bars are not the same. They have a different title. But I wouldn't expect that to cause the entire widget to recompose.