It's interesting that there seem to be a lot of ways to manage state with Compose. The ones with mut...

# compose

[iex]

It's interesting that there seem to be a lot of ways to manage state with Compose. The ones with mutability (e.g. Model annotation) don't resonate that much with me. I like the unidirectional flow with MVVM and live data. I'm considering implementing MVI like described here https://medium.com/swlh/android-mvi-with-jetpack-compose-b0890f5156ac but without the "innovation" of letting the state to directly create the Compose views. I'd let the fragment create those in response to the state. Are there any problems with this approach?

[iex]

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

[Adam Powell]

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

[Adam Powell]

(immutable being a stronger form of stable here)

[iex]

good to know! The article doesn't mention this

[iex]

thanks

[Leland Richardson [G]]

we are still playing around with some ways to infer immutability via whole program analysis potentially (or other means) and so haven’t spoken loudly about the @Immutable annotation so far as it may become unnecessary at some point

[Leland Richardson [G]]

but as adam mentions, the compiler will use the @Immutable contract to make optimizations. 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

[iex]

thanks again for all the infos!