Hi folks 👋 Question about smart recompostion. If I have a composable function like:

@Composable
fun CustomView(myObject: MyObject) { //some Compose UI }

If

MyObject

isn't marked

@Stable

will this method be recomposed regardless if the values of

MyObject

have not change?

It depends on what MyObject actually is and if the compiler inferred it as stable or not. The annotations are only to override what the compiler is inferring

Is there a list of what is inferred and what isn't? The

MyObject

for example, could be made of several

string

and

booleans

Follow-up question: Is this true for the

collectAsState

as well? For example, if I had a

Flow<MyObject>

and used

val myObject by someFlow.collectAsState()

? In others words, would the

remember

inside the collectAsState correctly compare if it compared two

MyObjects

(i.e. 2 emissions of the flow)?

state flows use distinctUntilChanged() under the hood, so if your object has a proper way to compare the values inside and you emit 2 of the same set of values, it shouldn't re-emit and in that sense should not force a recomposition it will, however, re-emit and recompose stuff if things change

I don’t actually understand what you mean. Equality and stability are two completely different things.

Ah ok, right. Thank you all!

For the record data class on other module are never marked stable, see https://chris.banes.dev/composable-metrics/ for how to actually check what it does. I made wrong assumptions on a few cases.

A class won't be considered stable if you don't apply compose compiler plugin to the module it lives in, not never considered stable.

Well yes but by default data class on different modules are shared or not compose related and people do not think to apply the compiler on them / annotate them. Hence why actually checking is important to verify assumptions. Typically the notion of same module is rarely mentioned about inferred stability.

I agree that it will be nice if there are more docs on stability inferring but again model classes and composable functions don't have to be in the same module.

Yes just apply the compiler I now know, but if you look at the @Adam Powell comment that is linked here a lot, there's no mention of same module or applying the compiler to the module containing that class. And without @cb article I would never have figured that small detail out as for most cases performance was mostly ok since the skipping worked at the lower level composable when passing the field values. But fixing that did increase perf a lot as enabled a huge tons of new skips at higher levels. So I'm assuming many won't think about that detail either.

Yes the linked article from @cb explains all that nicely.