Is it better to store individual class properties as Mutable

Question

Is it better to store individual class properties as MutableState or the whole class Example of what I mean in thread

vide · Answer

``` Screen 1 data class ScreenState val firstName String val lastName String Composable fun Screen val screenState = remember mutableStateOf ScreenState Hello World SomeComponent firstName = screenState value firstName lastName = screenState value lastName setFirstName = screenState value = screenState value copy firstName = it Screen 2 class ScreenState2 private val firstName = mutableStateOf Hello val firstName State lt String gt get = firstName fun setFirstName name String firstName value = name private val lastName = mutableStateOf World val lastName State lt String gt get = lastName Composable fun Screen2 screenState ScreenState2 SomeComponent firstName = screenState firstName value lastName = screenState lastName value setFirstName = screenState setFirstName Composable fun SomeComponent firstName String lastName String setFirstName String gt Unit TODO ```

vide · Answer

What is the practical difference here Any performance benefits

vide · Answer

I d prefer the second approach since especially with complex state I d imagine updating some deeply nested state would become quite troublesome with the first approach but is my intuition wrong here

ste · Answer

You could also do ```class ScreenState firstNameState MutableState lt String gt lastNameState MutableState lt String gt var firstName by firstNameState var lastName by lastNameState Composable fun rememberScreenState val firstNameState = rememeber mutableStateOf val lastNameState = rememeber mutableStateOf return remember ScreenState firstNameState lastNameState ```

Zoltan Demant · Answer

I think the latter approach is slightly better at least it should result in fewer recompositions if only one of the fields change

myanmarking · Answer

No i don t think that is true

Casey Brooks · Answer

I m strongly of the opinion that using a data class is much better than individual `States` for each property The high level reasoning is that it is difficult to combine those individual properties if you need to use both values at once but combining properties is trivial when the state is just an immutable data class I ve got a much more on how to model state in the documentation for my MVI library

myanmarking · Answer

exactly

agrosner · Answer

Much easier to reason about changes with a single data class for state

agrosner · Answer

Otherwise you can end up with many individual fields to manage

Colton Idle · Answer

For me I typically just have each screen state with a bunch of mutableStateOf Seems to work fine shruggie

agrosner · Answer

Idk if I recommend that either Why need that when compose does smart diffing anyways

myanmarking · Answer

for me one screen one data class

Colton Idle · Answer

Def seems to be stylistic differences but curious what the compose team says here I am but a simple noob at this stuff

Albert Chang · Answer

I think there are already many discussions on this For example <https kotlinlang slack com archives CJLTWPH7S p1652558519555569 thread ts=1652555947 214209 amp cid=CJLTWPH7S|this thread>

agrosner · Answer

Also the memory overhead of state for each smal string or variable And initialization overhead of registering each one Keep state small in places it s used and break the data class into smaller reusable pieces

vide · Answer

Thanks everyone for the answers smile