I’m trying to debug some piece of code. I narrow it down to this click listener: ```val onItemClicke...

# compose

[myanmarking]

I’m trying to debug some piece of code. I narrow it down to this click listener:

val onItemClicked = { index: Int ->
    listInfoState.animateScrollToItem(index)
}

Why would this cause the excess recomposition i am having, without evening triggering the click ?

[myanmarking]

wrapping with:

val onItemClicked = rememberUpdatedState(
    newValue = { index: Int ->
        listInfoState.animateScrollToItem(index)
    }
)

solves the issue. i don’t understand why

[mkrussel]

Since compose uses equality checks and onItemClicked will not be equal to the previous lambda that was created it triggers recomposition.

A cleaner option then using remembeUpdatedState could be to use method references listInfoState::animateScrollToItem

[myanmarking]

really? didn’t know that. let me try

[mkrussel]

I read a could article about this but cannot find it again

[myanmarking]

ya, but that won’t work. because the index i need to pass is provided elsewhere

[theapache64]

@mkrussel Are you looking for this? https://proandroiddev.com/understanding-re-composition-in-jetpack-compose-with-a-case-study-9e7d96d98095

[mkrussel]

Yeah that was the post I was thinking about

[myanmarking]

ya. in this particular case, the issue was that listInfoState was a custom implemented class, and although it was remembered, the class itself was not marked as Stable. That fixed the issue for me

[myanmarking]

but for sure i learned a lot about this corner cases regarding callbacks. one thing that helped me fix problems was using the

recomposeHighlighter

extension property suggested by google play team

[myanmarking]

i found some weird recompose problems when interacting with completed unrelated elements