https://kotlinlang.org
Join Slack
Hi folks :android-wave: Question about smart recompostion. If I have a composable function like: ```...
# compose
h
Hi folks 👋 Question about smart recompostion. If I have a composable function like:
Copy code
@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?
b
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
h
Is there a list of what is inferred and what isn't? The 
MyObject
for example, could be made of several 
string
and 
booleans
a
h
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)?
f
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
a
I don’t actually understand what you mean. Equality and stability are two completely different things.
👍 2
h
Ah ok, right. Thank you all!
👍 1
t
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
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.
t
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.
💯 1
a
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.
t
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.
z
t
Yes the linked article from @cb explains all that nicely.
2 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by