Hello here I was reading the Compose documentation about Man

Question

Hello here I was reading the Compose documentation about Managing states and I found this section <https developer android com jetpack compose state viewmodels source of truth> I m pretty surprised about this 1 The official recommendation is to link my ViewModel to Compose and no more emit my UiState with a StateFlow or a LiveData 2 If you have a data class here `ExampleUiState` as single source of truth for the UI and because you can t pass a state as parameter inside a Composable otherwise lint error does that means I m forced to redraw my entire screen at each change of my state Thanks in advance for your time

Adam Powell · Answer

for 1 using `mutableStateOf` is no more linked to composition and UI than using `suspendCancellableContinuation` is linked to flows For 2 this situation isn t any different from using `val uiState by viewModel uiStateFlow collectAsState ` at the same point do you have some code to share that you re concerned about

gpaligot · Answer

Thanks for your response Adam

gpaligot · Answer

1 Ok interesting but it requires Compose Runtime right Just we aren t forced to use Compose to emit UI

gpaligot · Answer

2 Yes if you are using a StateFlow you use `collectAsState ` and get the full model which force the recomposition of the screen maybe there is a performance issue with this function but if you are using `mutableStateOf` inside your ViewModel you get a state and you will force the recomposition only when you will call `state value` property It seems interesting to pass state as parameter to our composable functions to apply a recomposition to a subset of composables rather than the entire screen

gpaligot · Answer

I m aware that this brings others problems This seems a bad idea to share a state between multiple Composable but that could help performance thinking face

Adam Powell · Answer

Using snapshot state requires a dependency on the compose runtime artifact but it does not require using the compose compiler plugin

Adam Powell · Answer

As for where invalidations occur in the composition by reading snapshot state to a first order of approximation don t worry about it either way you can treat ```val uiState by myViewModel uiState collectAsState SomeComposable uiState ``` and ```class MyViewModel ViewModel var uiState by mutableStateOf UiState Initial private set SomeComposable myViewModel uiState ``` as identical They both invalidate when determining the parameter values to pass

Adam Powell · Answer

But this isn t always common usage in many cases you ll be pulling apart `uiState` in different places ```MyScaffold titleBar = AppBar uiState title itemContent = Item uiState items it ``` etc It might not be abstracted in a composable this way instead this might just be the result of placing different things in a combination of rows columns cards and your other custom containers in a single composable function You might combine different parts of `uiState` for some things and each combined piece might change in its own way over time as well

Adam Powell · Answer

If you want evaluation of some part of snapshot state to be lazy and invalidate only the part of the composition where it s used 1 measure that this is indeed causing a performance bottleneck for you first compose has a number of optimizations to try to make spine invalidation from the top cheaper It may have to recompose from the top but different sub branches will be able to skip if the parameters are stable and unchanged

Adam Powell · Answer

2 avoid using ` Mutable State lt T gt ` as the type of a parameter or public class property This is an implementation detail not API contract If you want to afford deeper invalidation use a lambda instead as it affords better flexibility for the caller ``` Don t Composable fun FancyItem state State lt SomeData gt SomeDeeplyNestedThing Text state value text ``` Instead do this ``` Do Composable fun FancyItem getState gt SomeData SomeDeeplyNestedThing Text getState text ```

Adam Powell · Answer

kind of a rough example but you get the idea

Adam Powell · Answer

I need to get the above into the public API guidelines slightly smiling face it s becoming a more common question

gpaligot · Answer

Definitely more clear now Thanks for all these explanations Yes I think this should be added in the official documentation

gpaligot · Answer

Today I don t have any performance issue with a state used by a lot of sub components from a screen component but I try to understand how it works to be sure it is okay

gpaligot · Answer

Thanks again for your response

Stylianos Gakis · Answer

I would love to see some official guidelines around doing <https kotlinlang slack com archives CJLTWPH7S p1644852772240549 thread ts=1644783454 508379 amp cid=CJLTWPH7S|this> To me as I ve never used it so far it feels non obvious so some quality documentation would be amazing