I *think* I am observing that even though @Composa...

# compose

[Travis Griggs]

I think I am observing that even though @Composables will rerun when their parameters change, if a closure for a pointerInput function closes over a simple value, prepared for a sub composable in that scope, that pointerInput may not be recomposed, resulting in the closure referencing a stale/old value. Would that be correct?

[jim]

Hard to tell from your abstract description, but that sounds fishy. Do you have a minimal example which demonstrates the issue?

[Travis Griggs]

Something like this:

ParentComposable
var selections by remember mutableStateOf(Set<Int>)
SubComposable(selections = selections)
mod = Modifier.pointerInput {
doThingsWith(selections)
}
SubSubComposable(modifier = mod)

I think that captures it. What I see is that under some cases, after selections has been changed, the doThingsWith() arg is an older version of selections.

[Alex Vanyo]

Yes, that is expected. pointerInput requires passing a key that controls when the block is cancelled and restarted. You have a couple options for how to handle that, depending on the behavior you want. The doc of pointerInput goes into more detail: https://developer.android.com/reference/kotlin/androidx/compose/ui/input/pointer/package-summary#(androidx.compose.ui.Mod[…]utines.SuspendFunction1)

[Travis Griggs]

I wonder if there is a learning style called "learning by need" 😄 That totally makes sense. I have read in "random access" mode ore than once. But the whole "key" thing was always kinda "hmmm...". And so many of the examples you find just use Unit as the key, so you do that. Simply adding the key to pointerInput(selections) { } made things work. And now that I need to understand this, it suddenly seems totally obvious. Thank you