One Off the Slack: Immutability and Changes
iex, like me, likes immutable objects:
I wonder whether not using
@Modelbut instead pushing down immutable objects with all the state will turn off optimizations or something?
Google’s Adam Powell pointed out the
If the objects are marked
@Immutablethen 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
MutableStateobject just creates a single point of mutation that compose can deal with properly (with some useful guarantees that
MutableStateprovides 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
StateFlow, or similar mechanisms, you are in great shape with respect to Compose.