can anyone give a straight answer on which is the ...
# compose
o
can anyone give a straight answer on which is the more preferred way? • Pass viewmodel to Composable using injection (hiltViewModel for example) • pass the functions that are needed from the viewModel as lambdas to the Composable • Random person on the internet’s invention? • Both 1 and 2, pass viewmodel so that you can get state and observe inside Composable, pass functions that let the Composable also run functions that manipulate state
p
In the root composable I pass a IRootComposableStateHolder interface which implementation provides the RootComposableXState. Reason for that is reuse my composable in desktop apps. Your composables shouldn't depend on Android specific classes. So hilt injects my RootComposableViewModel and I create a RootComposableStateHolder(RootComposableViewModel) then pass it to the top parent composable. Children composables just receive their corresponding State.
o
how hard would it be for me to see some sample code of this approach?
even though i think you explained it well
also, who in this scenario gets to manipulate the state? always the viewmodel yes?
c
The way I've been doing it is for a top level "screen" I inject VM via hilt. But basically the screen is just a small wrapper around the inner content where I pull apart the VM properties and events. This allows me to have the
Copy code
WrapperForScreenA(viewModel: MyVM) {
ActualScreenA(viewModel.something, ...)
}
and ActualScreenA is actually testable because it doesn't require a VM. I can just pass w/e i want to it.
p
I am working on a sample App to study compose related patterns. I will place the link 🔗
y
The stateful (view model, collect as state) and stateless pairs are a nice pattern. Same as @Colton Idle describes? Great for previews and testing. Pass in a state object (data class), and lambda.
s
And here is a practical example of this. One composable which uses hilt in this case to fetch the VM, and simply delegates everything to a composable which knows nothing about Android-specific stuff like AAC VM.
o
I really like this
thank you!
j
I like the idea but do not like the naming (suffix
Route
) 😅 Posted a discussion thread in the new #naming channel.