Hey there 👋 When searching for composable screens that could be recomposing unnecessarily I found out a screen which is basically a

LazyColumn

with mostly

TextFields

inside I noticed they were all recomposing on every key stroke for any of the fields. So if I type in something in the first field, the other fields, even though they did not change their value, will also recompose. After experimenting a bit I pinned it down to using the

onFocusChanged

modifier for these text fields. After removing the

onFocusChanged

modifier the text fields seem to skip composition. Is this the expected behaviour ? Quick repro (I am using the the recomposeHighlighter to visualize recompositions):

val state = remember {
      List(20) { it to "" }.toMutableStateMap()
    }

    LazyColumn(Modifier.fillMaxSize()) {
      itemsIndexed(state.values.toList()) { index, string ->
        TextField(
          value = string,
          onValueChange = { state[index] = it },
          modifier = Modifier
            .recomposeHighlighter()
            .onFocusChanged {  }
        )
      }
    }

If the onfocuschanged lambda content calls something not stable, it is possible it may be the cause. What are you doing in onfocuschanged?

I also thought that but it happens even when it is empty, like in the example I provided

Hm ok. Is that composable declared inside a fragment by any chance?

Ah interesting 🤔 In the app the text field is passed in through two composables (by passing a composable lambda), but the composable itself is created in the main composable I guess

ToMutableStateMap, is that stable?

I can test it a bit more tomorrow, thank you very much 🙏

Oh. The second item recompose is the focus change it makes sense

So after testing it a bit more the problem seems to be where the

onFocusChanged

modifier is created, so If the modifier is created in the main composable it recomposes for every new state there, if it is inside its own composable then it only recomposes when the state has changed. Wrapping the modifier with

remember

also works, but does not seem ideal