Is there anything that helps with understanding what caused a recomposition, or why a

@Compose

function is not being skipped?

Some notes I shared with my team the other day about Compose recompostuons: • Make sure any state objects you have only contain val and no var. This should be easy since state is supposed to be immutable anyways. • If you are using an interface as part of your state object, the interface has to be marked with @Stable or @Immutable so compose knows it can be used for smart recomposition • Currently Lists passed in trigger recomposition even if immutable. I believe there's a ticket for this to be fixed, one possible solution is to create a holder data class for lists that is marked immutable. • Implementing a lambda inline with a composable such as Header(onClick = { vm.handleclick() }) will cause recomposition. A few workarounds are: ◦ Hoisting up all unnecessary state and click handlers above the screen and passing them down ◦ Creating an anonymous object in a remember{} that holds all your click functions ◦ If your onClick takes no parameters, using method reference like ::onClick

Thanks, that’s useful, but is there nothing to help with debugging recomposition causes?

As far as I know there's not support for that yet (I could be wrong as this stuff moves fast)

Getting recomposition in a function that takes an enum and a Modifier 🤦

i think i heard from @Adam Powell a while ago, about there will be some debugging tools for getting the information which param cause recomposition.

Can confirm that streamlined tools are in the works.

Just FYI: The play store had an article recently that included a modifier for recomposition highlighting. https://github.com/android/snippets/blob/master/compose/recomposehighlighter/src/m[…]le/android/compose/recomposehighlighter/RecomposeHighlighter.kt