Hi guys. I have a question over the example given here - <https://developer.android.com/jetpack/comp...
a
Hi guys. I have a question over the example given here - https://developer.android.com/jetpack/compose/lifecycle#composition-anatomy. Based on https://medium.com/androiddevelopers/under-the-hood-of-jetpack-compose-part-2-of-2-37b2c20c6cdd my understanding was that
LoginInput
is supposed to be recomposed, because its position in the slot table is different. That seems not to be the case, according to the docs. So what am I missing here? Thank you in advance.
z
Not sure what you mean – are you asking if
LoginInput
would be recomposed if
LoginScreen
were called with a different value for
showError
?
a
Yes, my question is about
LoginInput
- docs state that it won't be recomposed. And this is a bit confusing for me - I though that a composable, which changes position in the slot table, is re-composed.
z
I believe that the compose runtime is smart enough to realize that it just “moves” around, and because it doesn’t require a recomposition for any other reason (it takes no params), it won’t recompose it just because there’s another group being added/removed before it.
a
Yes, I agree, that is exactly what docs say, but my question is more about "how does that work under the hood".
That question arises from the next section of the same doc - https://developer.android.com/jetpack/compose/lifecycle#add-info-smart-recomposition. In case of multiple invocations of the same composable from the same call site the compose runtime is not that smart and requires extra assistance.
z
Chuck recently gave another explanation of this, it might answer your question?
a
Yes, it might, thank you, I'll read it.
That's a great explanation, thank you, @Chuck Jazdzewski [G]. I still have a small question, though. Docs mention, that execution order might be a part of a Group key. Is that the case only when the same composable is called multiple times from the same call site or there are other scenarios?