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!