https://kotlinlang.org logo
Join Slack
Powered by
Hi everyone! What are the possible downsides of co...
# compose-android
г
Hi everyone! What are the possible downsides of configuring the Compose Compiler to consider everything stable? It seems that with the new stability config feature, one can just create a config file like 
**
And make every class stable and thus every composable skippable. According to Google's docs, the more skippable Composables, the better. Then why not just go ahead and do this?
e
if you use types that are marked stable but aren't actually stable, then your UI will fail to recompose when it needs to
г
I understand this, yet I've never actually faced such issues. What really seems to be an issue with some composable functions, especially "heavy" ones, like LazyRow and LazyColumn, is their recomposition on every recomposition of their parent. For example, if you pass your view model to such a composable and forget to mark the view model with a Stable annotation, playing an animation on a parent can have a detrimental impact on app's performance. My personal 2-year experience with Compose have led me to the conclusion that it is better to recompose as little as possible and if something does not recompose as expected - better deal with these individual cases.
e
if you start correct but slow, and then fix performance issues as you discover them, the end result will still be correct. if you start fast but incorrect, and then fix correctness issues as you discover them, you do not know that your end result is correct.
s
We also introduced a "strong-skipping" mode which does exactly that, but compares unstable values by reference instead of by value
г
Can you pls elaborate a bit more on this strong skipping mode? How can I enable it? Somewhere in the Gradle scripts?
Oh, just found it) Thanks
b
4 Views
Open in Slack
PreviousNext
Powered by