I try to observe any significant difference betwee...
# compose
m
I try to observe any significant difference between using stable and unstable types with Strong skipping mode enabled, and I have trouble finding any substantial example. The key difference is that unstable types are compared with ===, and stable first with ===, and if it returns true by ==. To observe the difference, I would need to literally provide a new object that is equal to the previous one. I cannot imagine any reasonable code that would do that. Do you have any examples/experiences in this?
s
Creating a new list each time, which is == but not === is one of the very common ways where this happens
m
Can you show me an example?
Why creating a new list if it has the same elements?
Ok, I guess if this list is a part of an object that is fetched from some API 🤔
s
If it's created in composition but not inside a
remember
would be a good example I think
m
Ok, I can see it
Do you have any example why can't an unstable object be compared by == as well?
s
Yeah, in case a class has implemented the equals function incorrectly. Or if it has mutable state internally which is not backed by mutable state. Although I suppose even === in that case might be giving the wrong results
m
Yes, compose is not dealing with mutable objects well as they cannot be observed.
I try to understand the class of objects that: 1. Are safe to be used in compose 2. Are not immutable
I guess it is about things like view models 🤔
a
This is very common. Consider this example.
Copy code
@Composable
fun Screen(
    text: String,
    list: List<String>,
) {
    Column {
        Text(text)
        List(list)
    }
}

@Composable
fun List(
    list: List<String>,
) {
    LazyColumn(list)
}
When
text
changes, the whole
Screen
, including
List
, will be recomposed, and
List
can only be skipped if strong skipping mode is enabled.
Or maybe I misunderstood your question.
m
In this question I assumed strong skipping mode is enabled, so there List is not recomposed.
g
and stable first with ===, and if it returns true by ==
if
===
returns true, then there is no point in doing also
==
, given that
===
is stronger than
==
. Usually the instance equality check is the first line of a proper
equals()
implementation (and probably the runtime never checks stable types with
===
, but only
==
)