I have a data class annotated with

@Stable

and would expect that a change to the property would reflect the new state but it doesn't:

@Stable
data class StableState(var isChecked: Boolean)

@Composable
fun StableTest(state: StableState) {
    Checkbox(checked = state.isChecked, onCheckedChange = {
        state.isChecked = it
    })
}

What did I miss?

Your class is not actually stable. https://developer.android.com/reference/kotlin/androidx/compose/runtime/Stable You are not meeting requirement 2. Any writeable property in your

Stable

class should get reported back to compose through a compose state object.

ok I guess I don't understand the second point. Doesn't it mean that when the property changes, recomposition is triggered?

A version of

StableState

that is stable with the same interface could be:

@Stable
class StableState(isChecked: Boolean) {
    var isChecked by mutableStateOf(isChecked)
}

It means that you have a

State

variable in your object that changes when that property changes. I believe the state can be private and it will still work. Not sure if it is possible to have a stable non immutable data class

Compose doesn't automatically augment your classes to make them reactive, it still needs you, the programmer, to tell Compose which variables should be reactive. Replacing

var

with

val mutableStateOf

is the main way to make a property able to notify Compose of changes

Ahh ok, but there is one thing I still don't understand. How does some of Compose internal state classes work, e.g.

@Stable
    private class SnackbarDataImpl(
        override val message: String,
        override val actionLabel: String?,
        override val duration: SnackbarDuration,
        private val continuation: CancellableContinuation<SnackbarResult>
    ) : SnackbarData { ... }

or

@Stable
class DrawerState(
    initialValue: DrawerValue,
    confirmStateChange: (DrawerValue) -> Boolean = { true }
) { .. }

I see here primitives not

State

objects.

You're free to use normal variables (val or var), and Compose will always read them just fine the first time. But notice that the properties in

SnackbarDataImpl

are all `val`s, meaning the class is immutable. Compose has no need of ever recomposing on any particular property in the class. Since nothing in the class could ever change, the corresponding UI will always be the same. To actually update the UI with a new snackbar, you'd replacce the old instance with a new instance, which Compose would detect as a change and then update the corresponding parts of the UI as a result. But Compoe will only know that there's a new Snackbar when a

mutableStateOf

has that new snackbar instance set to it.

Ahhh I got it. Thanks Casey and the other guys ❤️

The snackbar seems slightly different, since you're setting the data to a "handler", but behind-the-scenes the handler is just forwarding the snackbar data to a different part of the UI tree (the snackbar host), where it reads a

State

variable and displays the actual snackbar data as anything else would. The same pattern holds for scrolling, ripples, genreic animatioons, and everything else. The data behind the whole of Compose is always immutable at the data class level, or else uses

mutableStateOf

to make sure Compose knows when something changes

Yeah I should have had a look into the compose-api-guidelines. Thanks for the insights