# compose

Travis Griggs

10/12/2023, 5:48 PM
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?


10/12/2023, 5:52 PM
Hard to tell from your abstract description, but that sounds fishy. Do you have a minimal example which demonstrates the issue?

Travis Griggs

10/12/2023, 5:56 PM
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

10/12/2023, 6:09 PM
Yes, that is expected.
requires passing a
that controls when the
is cancelled and restarted. You have a couple options for how to handle that, depending on the behavior you want. The doc of
goes into more detail:[…]utines.SuspendFunction1)
🙏 1

Travis Griggs

10/12/2023, 6:20 PM
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