Say I have a data class with two properties - one that is declared in primary constructor, one as “normal” property. A

livedata

of said data class was part of state in my view model. I started to observe it as state. What I found out is, I believe, is an optimisation that compose is applying, but correct me if I’m wrong here. When I

postValue

with a new data class, with changed property that is declared in primary constructor,

compose

catches that and triggers recomposition on state - so that’s correct. Now,

postValue

with my data class with a change to a property that was not part of the primary constructor -

compose

does not trigger recomposition, even if observer in

observeAsState

is triggered.

Looked into this recently.

observeAsState

uses the default form of

mutableStateOf

, which uses

structuralEqualityPolicy()

to compare new states with old states:

fun <T> mutableStateOf(
    value: T,
    policy: SnapshotMutationPolicy<T> = structuralEqualityPolicy()
): MutableState<T> = SnapshotMutableState(value, policy)

Digging further,

StructuralEqualityPolicy

is implemented like this:

private object StructuralEqualityPolicy : SnapshotMutationPolicy<Any?> {
    override fun equivalent(a: Any?, b: Any?) = a == b
}

So your theory is correct, it's an

equals

check.

Nice breakdown. Checked the code myself now and it answer my question, thanks!