New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ViewModel POC #303
ViewModel POC #303
Conversation
) : Node( | ||
buildContext = buildContext | ||
) { | ||
private val activity = (integrationPoint as ActivityIntegrationPoint).activity |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can wrap all required code in a less uglier way exposing only VM factory
samples/sandbox/src/main/kotlin/com/bumble/appyx/sandbox/client/viewmodel/ViewModelExt.kt
Fixed
Show fixed
Hide fixed
samples/sandbox/src/main/kotlin/com/bumble/appyx/sandbox/client/viewmodel/ViewModelExt.kt
Fixed
Show fixed
Hide fixed
d627b2c
to
56c9e81
Compare
IMHO it should be implemented in the same way as in Anyway in both variants we have another problem – we change DI flow. We usually pass all dependencies into |
This is what we're doing internally right now. I've published a sample demonstrating this |
yes, that's what I was gonna do as a second option |
The standard lifecycle viewModel functions for compose delegate to the composition local LocalViewModelStoreOwner. Wouldn't it just be a matter of coming up with a proper implementation of this which was aware of the navigation graph, and setting up the composition local for each node? (Yes, i know i'm making the implementation seem simpler than it probably would be) I honestly wonder how compose navigation achieves this. Update: I took a look and it seems like NavBackStackEntry itself implements several interfaces including the LifecycleOwner and ViewModelStoreOwner. So what i assume happens is that as each backstack entry is created, a completely new store is instantiated and registered as the local store owner. And when it's popped off, it is completely cleared. This makes a ton of sense to me obviously, and I think it could honestly be done in this library as well. |
Hi @mattinger we're considering the same approach in this draft pr but the final decision whether to make it as a part of framework hasn't been made yet. We recently introduced RetainedInstanceStore which allows you to implement ViewModel support the way you described right now |
Description
This PR demonstrates how VM can be used and scoped to a
Node
using reflection API.By design VM is stored in a
ViewModelStore
class and lives as long as activity lives.The desired behaviour is the following:
VM
is created whenNode
is createdVM
is persistent whenNode
is moved inDESTROY
state andActivity
is changing configurationVM
is destroyed whenNode
is moved inDESTROY
state andActivity
IS NOT changing configurationThis behaviour can not be achieved using public API as it's not possible to clear only one
VM
fromViewModelStore. It has only one public method –
ViewModelStore.clear()which clears all
VMs.I the meantime I'm exploring alternative solutions.
vm.mp4
Check list
CHANGELOG.md
if required.