One Off the Slack: Immutability Is Your Friend
As with last week’s highlighted Slack thread, this one focuses on state change detection and mutability.
Colton Idle asked:
My activity has a field myTodoList mutableListOf
and it has items added to it by another source (right now I have a post delayed handler that waits for 5 seconds, and then adds ten items) and I expect the items to update this Screen composable, but nothing shows.
Mutable stuff (
MutableList, etc.) is fine, but Compose knows nothing about
it. On the whole, Compose — particualarly
State — works much better
with immutable objects.
As Florian Schuster put it:
Your problem lies not in compose but with your list in your activity. The list needs to be observable if you want your composables to recompose on a change of the items in the list. Either use a Flow
or mutableStateOf(List), hand that over to your MyActivityScreen and observe it in there.
Colton then tried:
val listOfItems = mutableStateOf(mutableListOf<String>())
However, this still uses
MutableState know when
you supply a fresh value, but they do not know when you change the internals
of the existing value, such as adding an element to the
val listOfItems = mutableStateOf(listOf<String>())
listOfItems.value = listOf("a", "b" )
And in the end that wound up being the solution.
In general, in Kotlin, prefer immutable things to mutable ones (
val instead of
List instead of
MutableList). Unidirectional data flow architectures tend to rely
on this convention, and Compose leans into it as well.