A modern programming language that makes developers happier.

kotlinlang

Hello, why is recomposition happening in this example even when no parameters has changed and how can I avoid it?

In this example, I have two buttons. When I click for example on first button, my state changes, but I would expect only the FirstButton Composable to be recomposed because in SecondButton composable nothing changed.

```class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val stateFlow = MutableStateFlow(State(0, 0))
        setContent {
            MyComposeTheme {
                val state by stateFlow.collectAsState()

                Column() {
                    FirstButton(
                        text = state.firstNumber.toString()
                    ) {
                        stateFlow.value = stateFlow.value.copy(firstNumber = Random.nextInt())
                    }

                    SecondButton(
                        text = state.secondNumber.toString()
                    ) {
                        stateFlow.value = stateFlow.value.copy(secondNumber = Random.nextInt())
                    }
                }

            }
        }
    }
}

@Composable
private fun FirstButton(
    text: String,
    onClick: () -&gt; Unit
) {
    Button(
        onClick = onClick
    ) {
        Text(text = text)
    }
}

@Composable
private fun SecondButton(
    text: String,
    onClick: () -&gt; Unit
) {
    Button(
        onClick = onClick
    ) {
        Text(text = text)
    }
}

data class State(
    val firstNumber: Int,
    val secondNumber: Int
)```


I guess it's because you read the value in the second button. Maybe this article helps : <https://dev.to/zachklipp/scoped-recomposition-jetpack-compose-what-happens-when-state-changes-l78>

Function arguments in Kotlin are always passed by value, so they're evaluated before actually invoking the function they're being passed to. That means you're reading the state in the higher level composable here. 

But that's fine - there's nothing inherently wrong with this code. Compose will still skip things where it can. 

I see, but what if I have a state and one of the fields is for example position in a video player that is updated very often. I am using this position in composable A. But then I have another field in this state - video size, that I am using in composable B. This means that composable B is also recomposed as much as composable A, even when it does not have to, moreover there is also an AndroidView in Composable B, where I am setting the video size inside update callback. Is it still fine in this case?

Right, so that’s probably also fine, since you’d probably be passing the seek position into a composable as a regular param anyway. But if the state is used by a later phase (eg layout or drawing), then you can refactor how you store your state so you can defer the state read until the latest point where you actually need it and skip having to recompose at all when it changes. But in this case it’s not worth refactoring just for that reason.

If those fields are put together like in a dataclass as state, then yes but maybe it could work if you extract one of those field and make it a state of its own by using derivedStateOf f.e

<@U0KMMQA20> thank you for your great article I linked above. It really helped me out a lot! :ok_hand::ok_hand::+1: