One Off the Slack: Immutability and Changes

iex, like me, likes immutable objects:

I wonder whether not using MutableState or @Model but instead pushing down immutable objects with all the state will turn off optimizations or something?

Google’s Adam Powell pointed out the @Immutable annotation:

If the objects are marked @Immutable then they will be compared to previous parameter values and a composable function call will be skipped if the parameters are stable and equal

Though Google’s Leland Richardson agrees with the immutable-data approach:

Compose very much likes immutable objects wherever possible. The MutableState object just creates a single point of mutation that compose can deal with properly (with some useful guarantees that MutableState provides you) since most applications will need to have a point of mutation somewhere as state changes over time

However, he also points out that they are hoping that @Immutable will not be needed in the future, if the compiler plugin can determine immutability by other means.

But, in a nutshell, if your architecture is already set up to have a stream of immutable objects (e.g., view states), published via LiveData, StateFlow, or similar mechanisms, you are in great shape with respect to Compose.

Read the original thread in the kotlinlang Slack workspace. Not a member? Join that Slack workspace here!