I've got a new team member that keeps defining com...
# compose-android
c
I've got a new team member that keeps defining composables with
MutableState<Bar>
as arguments instead of just
Bar
. I want to point to some documentation about this but I'm coming up empty. I could have sworn the android docs had something very clearly about this sort of pattern. Does anyone remember by chance?
e
The state hoisting section mentions it, but not explicitly:
The general pattern for state hoisting in Jetpack Compose is to replace the state variable with two parameters...
There's also a detekt rule for it
c
yea im looking for an explcit mention of it (i swear it exists somewhere)
e
You're correct, there was explicit mention of it somewhere, I just don't remember where either.
❤️ 1
w
I also went digging for a very long time for this earlier in the week and I couldn't find it. Maybe it's buried in Compose source/API guidelines somewhere.
@Zlata did you use an LLM to find that link as well, or did you already know about it 😅
z
I used an LLM 🙈
same 1
w
I did try asking Gemini but it didn't end up sourcing the source, could only link me to articles/DAC. How did y'all prompt it? I could've also just gotten unlucky.
e
I did a "deeper search" on Grok with this prompt:
Can you find an explicit mention in Android Compose documentation, not to pass a MutableState<T> as a parameter to other functions, but instead to pass its value, and a lambda to update it? To be clear, I'm looking for explicit mention of not passing a MutableState<T>, and not just the alternative of the value and lambda.
👍 1
c
Ah. theres two docs
thanks everyone!!!
m
A very helpful thread. Definitely saving this...