Question about recomposition granularity Given this composable with state:

data class State(
    val firstCounter: Int = 0,
    val secondCounter: Int = 0
)

@Composable
fun MyScreen(
    stateFlow: StateFlow<State>,
    onClick1: () -> Unit,
    onClick2: () -> Unit,
) {
    val state by stateFlow.collectAsState()
    Column {
        Button(onClick = onClick1) {
            Text(text = "One ${state.firstCounter}")
        }
        Button(onClick = onClick2) {
            Text(text = "Two ${state.secondCounter}")
        }
    }
}

If only one field of the

state

object changes will it trigger recomposition of only one (the one that’s reading that field) or both buttons ? Can someone point to some docs or examples to learn a bit more how recomposition actually works? 🙏

I see you edited it a little bit, but taking your previous version and defining

MyButton

like that:

@Composable
fun MyButton(text: String, number: Int, onClick: () -> Unit) {
    onCommit(callback = {
        Log.i("MyButton", "committed: $text, $number")
    })
    Button(onClick = { onClick() }) {
        Text(text = "$text value: $number")
    }
}

you can discover it by yourself 🙂 From the documentation:

The onCommit effect is a lifecycle effect that will execute [callback] every time the composition commits.

So, if I’m not mistaken this callback is called every time recomposition happens 🙂

Great thanks! That’s actually the case when I define my activity as:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val stateFlow = MutableStateFlow(State())
        setContent {
            MyApplicationTheme {
                MyScreen(
                    stateFlow = stateFlow,
                    onClick1 = {
                        stateFlow.value = stateFlow.value.copy(
                            firstCounter = stateFlow.value.firstCounter + 1
                        )
                    },
                    onClick2 = {
                        stateFlow.value = stateFlow.value.copy(
                            secondCounter = stateFlow.value.secondCounter + 1
                        )
                    }
                )
            }
        }
    }
}

there are several factors at play here, both invalidation and skipping.

Wow! This was a lot to swallow all at once :) Let’s double check with one last example: Example 1:

val state by stateFlow.collectAsState()
    Column {
        // Scope A
        Button(onClick = onClick1) {
            // Scope B
            Text(text = "One ${state.firstCounter}")
        }
        Button(onClick = onClick2) {
            // Scope C
            Text(text = "Two ${state.secondCounter}")
        }
    }

In example 1

state

is read twice, one from within Scope B and one from within Scope C. Example 2:

val state by stateFlow.collectAsState()
    Column {
        // Scope A
        MyButton(
            text = "One ${state.firstCounter}",
            onClick = onClick1
        )
        MyButton(
            text = "Two ${state.secondCounter}",
            onClick = onClick2
        )
    }

In example 2

state

is still read twice, but both reads happen within Scope A. Therefore when

state

changes: - In example 1 both `Button`s are always invalidated and re-run, but any

Text

composable whose input

text

param doesn’t change is skipped. - In example 2 it’s actually

Column

that gets invalidated and re-run, but any

MyButton

composable whose input

text

param doesn’t change is skipped. Can this “skipping” be regarded as some form of memoization? Thanks a lot for the explanation!

At a high level, yes, you've got it. Stability determination throws a bit of a wrench into when we can skip and still be correct occasionally, so I'm deliberately hand-waving a bit here

Stability determination throws a bit of a wrench into when we can skip and still be correct occasionally, so I’m deliberately hand-waving a bit here

In fact while writing I wasn’t sure whether the

onClick

param could actually prevent the skipping for

MyButton

: one thing is to check equality on a string, but checking it on a lambda doesn’t seem equally simple.

yes that's exactly right re. the

onClick

lambda. Setting a

StateFlow

value in that lambda as opposed to setting a

mutableStateOf()

snapshot state object (which we know is stable) likely behaves differently here.

Can this “skipping” be regarded as some form of memoization?

This is exactly what it is but we call it Positional Memoization because we consider the "position" of the call in the call graph as an implicit memoization parameter.