A basic compose question. If the inputs of a Compo...

# compose

[Arjan van Wieringen]

A basic compose question. If the inputs of a Composable are the same, it is skipped right? However, in my case:

@Composable fun Icons(
    icons: List<IconState> = listOf(),
    iconEventHandler: IconEventHandler? = null,
) {
    icons.forEach { element ->
        Icon(
            iconState = element,
            onClick = { iconEventHandler?.onClick(element) },
            onDragStart = { offset -> iconEventHandler?.onDragStart(element, offset) },
            onDrag = { offset -> iconEventHandler?.onDrag(element, offset) },
            onDragEnd = { iconEventHandler?.onDragEnd(element) }
        )
    }
}

The icons states are the same, but the lambda's passed to the Icon composable have different hashcodes every time, and as such it rerenders. I guess it makes sense, because Kotlin can not determine structural equality of lambdas. However, this must be a common pitfall then? What could I do to improve the performance? Push the iconEventHandler insode the Icon composable?

[Ian Lake]

Have you considered using rememberUpdatedState? That's what can capture a lambda as a long-lived state object that doesn't change hashcodes: https://developer.android.com/jetpack/compose/side-effects#rememberupdatedstate

[Arjan van Wieringen]

Sure. But isn’t passing lambdas to composables are very very basic function? I haven’t seen rememberUpdatedState anywhere in documentation for this?

[Ian Lake]

Recomposition, by itself, is not a problem or something that indicates a performance issue. You actually need to trace to see if that recomposition is actually expensive

[Ian Lake]

And I'm pretty sure I just linked to the documentation, right alongside DisposableEffect and other APIs 🙂

[Arjan van Wieringen]

Yes I understand. And thanks for your help!

[Francesc]

note that List is not stable, if you want to avoid recompositions with collections consider using immutable collections

[Arjan van Wieringen]

At @Francesc , I already to that in the underlying view model. List is the interface, PersistentList is the implementation