# compose

Colton Idle

08/10/2022, 7:02 PM
Been writing compose apps for like a year+ (3 fully compose apps shipped to prod) I've never written
in any of my codebases. 🙈 Am I missing something basic here? Should I be marking classes as stable?


08/10/2022, 7:03 PM

Sean McQuillan [G]

08/10/2022, 7:05 PM
You’re good ignoring it. It’s a useful tool for helping hint some skipping, but tbh I’d say you should have evidence of it’s need prior to applying it.

Colton Idle

08/10/2022, 7:09 PM
gotcha. From what I picked up in context clues while lurking in #compose over the past year is that classes have to be "stable" in order for compose to be able to recompose properly... but yeah all of my state is typically just
Copy code
class Foo {
   var fieldA: Boolean by mutableState...
   var fieldB: String by mutableState...
   var fieldC: List<String> by mutableState...
   var fieldD: List<SomeDataClass> by mutableState...
and so I assumed that's "stable".

Landry Norris

08/10/2022, 7:13 PM
I’m not even sure that it helps. I have a composable that seems to recompose everything, regardless of what actually changed. I marked my state class as Stable, and it still recomposes everything. Tried Immutable, and same thing.

Colton Idle

08/10/2022, 7:18 PM
Hm. That seems somewhat problematic? you should file a minimal repro case if possible.

Bryan Herbst

08/10/2022, 7:24 PM

Sean McQuillan [G]

08/10/2022, 8:18 PM
To clarify one important point: Recomposition without any stables will be “correct”
Adding @Stable is not necessary for correctness, and if used incorrectly it can lead to faults in recomposition
It just helps increase skipping, which can improve performance.

Zoltan Demant

08/11/2022, 7:50 AM
Your mileage may vary, but I saw pretty great performance improvements by annotating my models with `@Immutable`; especially during animations. I just wish we could specify stability for external classes, but wrapping where needed has been a good alternative for now 🙂