I can't find anything in the docs, but when using ...

# compose

[Tolriq]

I can't find anything in the docs, but when using Crossfade in a column with a composable that add multiple views the views are stacked and not in columns as it is without the Crossfade. Is this a normal behavior?

[Tolriq]

Well reading the source it wraps in a Box so it's normal behavior even if strange.

[Colton Idle]

@Tolriq did you use to hang on the old android-dev freenode IRC channel. Name sounds familiar and I think you helped me out a bunch.

[Tolriq]

Nope my IRC time was before dev 🙂 But this nick name is pretty rare.

[Doris Liu]

Curious about your expectation here, were you expecting the children of Crossfade to be laid out based on the parent layout? 🙂

[Tolriq]

@Doris Liu I was expecting the Crossfade thing to be purely animation / decorator based so yes not changing how what I wrapped in it to change. When you know it's internal it's logical and makes senses to break the Column. But when you have a layout working and decide to add this to test animations and see all broken, it's hard to make the dots. (Also probably because I lack Compose experience) I assume adding another Column wrapper inside the Crossfade does not have performance impacts. But it's currently also hard to know what have performance impacts what not 😞

[Doris Liu]

Here's a tip that may help you differentiate: If a composable takes a modifier, it's pretty much safe to assume that it's going to be a layout of some sort, instead of pure decorator. Do you have a video/mock for your use case? Maybe it can be done with a modifier (which would be a pure decorator without impacting the layout arrangement).

[Tolriq]

It was mostly a test to switch a full screen except a top element, from 3 cards to a lazycolum + a bottom row. So kinda a screen transition with a shared action bar since there's no shared transition yet. I guess for a generic use case there's not a lot of choices to animate a navigation between part of the screen.

[Tolriq]

And unrelated but you probably know a an expert 🙂 What is the proper way to have a lazycolumn feed from a stateflow of a list of elements to only recompose the changed elements and not all the visible elements if possible. Like a list of downloadItems with a progress bar and a speed changing fast for just one or 2 "active" elements with the others not changing.

[Doris Liu]

DiffUtil equivalent for Lazy* is not supported yet. I can't seem to find an issue tracking that. @Andrey Kulikov would know.

[Tolriq]

Thanks for confirming I'm not mad. Tested a lot of stuff this afternoon, maybe it's worth a small note somewhere, as everything state that everything is magic and only recompose when needed but not the caveats like this one.

[Andrey Kulikov]

if you add/remove/move items of LazyColumn you need to provide keys for your items in order to help LazyColumn to handle it smarter(see the second optional param on item/items function). but in general the fact that all the visible items were recomposed once when you changed the list it doesn’t necessary mean it is bad. one layer of composable functions would be recomposed, but most of the item content(inner composables invocations) will be skipped based on the regular compose logic if the parameteres didn’t change. so we don’t really have/need a direct DiffUtil replacement

[Tolriq]

Makes sense, but then how can we debug / trace / ensure what happens in the inner components to be sure that we did not miss something? From pre compose way textview measure on wrap_content are costly, so it's nice to be sure it is not happening in those cases.