0

Are there any valid reasons to make a UI data class property mutable?

For example: I have an app that allows users to send messages with polls with multiple choices using Checkboxes. I want ViewModel to maintain state of checkbox through both recompositions and activity destruction (due to device rotation). If I'm developing with Jetpack Compose, rememberSaveable does not preserve state through activity destruction (at least on my android phones), but ViewModel will.

My current solution introduced a mutable property in the data class for the checkbox element that would 'remember' whether the box was checked. Since objects of checkbox class were held in VM, they survived orientation changes.

Regress.arg
  • 352
  • 6
  • 16
  • Changing a mutable property won't trigger automatic recomposition, so you'll have to track it manually. If the benefits of having such a property exceed the inconvenience caused by the need to manually track changes, then why not. But in the case you described, I don't see any need for mutable properties. – bylazy May 30 '23 at 18:20
  • Generally the entire design principle of compose is to keep view layer state-less so there's only a single source of truth to maintain. Storing a "checkbox" state in composable that has to be double checked against current value in viewmodel is exactly what compose aims to eliminate. – Pawel May 30 '23 at 21:02
  • The mutable property is itself a mutable state, so it ends up triggering the recomposition. And composer's statelessness is a problem when config tree destroys the compose tree entirely. Remembersaveable hasn't been working either – Regress.arg May 31 '23 at 04:23

0 Answers0