I'm working my way through an Animation codelab, and a common one is to add .animateContentSize to R...

# compose

[Travis Griggs]

I'm working my way through an Animation codelab, and a common one is to add .animateContentSize to Rows and Columns. What are the negatives to just doing this by default? I know with UIKit code, things just generally animate unless you need them not to. But the norm here, seems to be to have to turn a lot of animation on. Does it hurt to just turn these on by default, but turn them off when problematic?

[Doris Liu]

The biggest consideration here is clarity. By requiring opt-in to animate, developers would know exactly which layout has the animation enabled and hence would have an easier time debugging if something didn't animate as expected. In contrast, if layouts all animate by default, it'd difficult to narrow down the cause if the animation didn't behave correctly. In addition, customizing animation is more straightforward when you opt-in to animation, since it's on the same code path as where the animation is created.

Another consideration is performance. Even though animateContentSize is animating at the measure/layout phase, it is possible that the per-frame size change can invalidate subcompositions elsewhere in the tree, which may have performance implications. When you define animations explicitly, it is much easier to notice such performance impact and restructure your layout as needed.