I was doing some good old fashion println debugging, and noticed that in some state (that I haven't figured out yet), I get endless compose updates in one of my Canvas compositions. It's like there's a cyclic update or something. This has led me to wonder if there are caveats on what kinds of things you can/should put in a

remember { mutableStateOf() }

thing. For example, in one place I have a

var visibleInterval by remember { mutableStateOf<ClosedRange<Duration>> }

and in another a

var selections by remember { mutableStateOf<Set<Int>>(emptySet()) }

. Are either of these expressions problem prone?

I can't spot anything wrong with those statements, have you perhaps done a backwards write? https://developer.android.com/jetpack/compose/performance/bestpractices#avoid-backwards

I don't think I am 🙂 My top level code just looks like:

var selections by remember { mutableStateOf<Set<Int>>(emptySet()) }
// LaunchedEffect(selections) {
//    selections.logged("SELECTIONS CHANGED")
// }
   SpansView(
      plan = PlansRepo.rapidPrecisionPlan(),
      selectAction = { op, arg -> selections = op.update(selections, arg) },
      selections = selections,
      modifier = Modifier.fillMaxSize()
   )
}

As soon as that selectAction fires, the SpansView starts repeatedly composing. But the selectAction itself is not repeteadly firing.

Check Inside the effects, if you are not triggering changes that causes State to change and so on. Happens to my once in some code that I had in the composable function scope rather than in the DisposableEffect {} block

Yeah, I don't have any other effects other than the one shown as commented out there

I see, well start removing code chunks until you find the culprit

You might be able to see what's changing by putting a breakpoint in the canvas and checking the "Recomposition State"

I see the call to rapidPrecissionPlan() happens in a the Composable scope. Is the only suspicious thing

it's just my preview

Interesting 🤔 Wonder what changed and dirty means

Sigh. I should have @Pablichjenkov right away. It didn't don on me that my top level Preview would be recomposing as well. I hadn't checked that. But alas, it was. Which means it was fetching a new instance of the PlansRepo.rapidPrecisionPlan(). Paying attention to the SpansView stack on each rerun, I noticed that the Plan object address was changing! So I was getting a new one. Since it has mutableStates down in there, that must have been triggering recompositions? Fixing it was even weirder. My first though was, "oh, i guess since the remember selections is right here, this too (re)composes, not just the functions that are using it. So I'll isolate those:

private fun SpanViewPreview() {
   val plan = PlansRepo.rapidPrecisionPlan()
   Box(modifier = Modifier.fillMaxSize()) {
      var selections by remember { mutableStateOf<Set<Int>>(emptySet()) }
      SpansView(
         plan = plan,
         selectAction = { op, arg -> selections = op.update(selections, arg) },
         selections = selections,
         modifier = Modifier.fillMaxSize()
      )
   }
}

but alas, this had no effect. Then, I remembered that Box is an inline function, so no real no composition nesting is actually happening there. So changing it to

private fun SpanViewPreview() {
   val plan = PlansRepo.rapidPrecisionPlan()
   Surface(modifier = Modifier.fillMaxSize()) {
      var selections by remember { mutableStateOf<Set<Int>>(emptySet()) }
      SpansView(
         plan = plan,
         selectAction = { op, arg -> selections = op.update(selections, arg) },
         selections = selections,
         modifier = Modifier.fillMaxSize()
      )
   }
}

suddenly works. Because, for the time being, apparently, Surface is not an inline function for its content.

You can use a LaunchEffect or a produceState effect I guess.

That PlansRepo.rapidPrecisionPlan() produces equal (but not identical) instances. If I implemented hash/equal for Plan such that the hash equality was stable, even though they're different instances, would that have headed this issue off?

That is the trick, don't write code in composable functions that is not Composable. Used effects for that, or remember. And last but not least, it is a good practice to remember with keys if you want it to get updated with the input params. Otherwise, it will keep the value from the previous composition. It probably doesn't apply to you since you are using a singleton but just in case

"Wonder what changed and dirty means" changed and dirty are bitmasks that are part of the code the compose compiler is generating, it's what it is using to determine whether to skip or not. The recomposition state part of the debugger is parsing those bitmasks for you to something more readable