Material's Colors has all its fields as a state - ...

# compose

[Jan Skrasek]

Material's Colors has all its fields as a state - documented as an optimization to when the color changes not to recompose everything, but only composables depending on the particular color.
But I can't find any place that would modify any color. So is this a preoptimized for some user-land use-cases? And what they could be?

[Adam Powell]

Animating theme colors

[Jan Skrasek]

Is such animation used in compose?
The only one I can think of is going from light to dark. Or any other reason?

[Louis Pullen-Freilich [G]]

Jetcaster animates the primary color of the app depending on the podcast artwork, for a real-life example

https://github.com/android/compose-samples/tree/master/Jetcaster

[Jan Skrasek]

Thanks, great example!

[Jan Skrasek]

I've taken a look and it doesn't seems that Jetcaster would modify the state, instead it copy() the colors & provides new ambient value, isn't it?

https://github.com/android/compose-samples/blob/dcc400da3fb8e09b99b5fb21fced77c60e04393d/Jetcaster/app/src/main/java/com/example/jetcaster/util/DynamicTheming.kt#L63-L67

[Louis Pullen-Freilich [G]]

Exactly, MaterialTheme internally modifies the state, it's a performance optimization for the internals, but isn't consumer facing

https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:compose/material/material/src/commonMain/kotlin/androidx/compose/material/MaterialTheme.kt;l=63

Internally we just update the initial theme provided, with colors from the new object, instead of replacing the object in the ambient value

[Jan Skrasek]

Oh, I see it. I think the trick is here:

val rememberedColors = remember {
    // TODO: b/162450508 remove the unnecessary .copy() here when it isn't needed to ensure that
    // we don't skip the updateColorsFrom call
    colors.copy()
}.apply { updateColorsFrom(colors) }