IMHO it should be implemented in the same way as in Fragment – each Node should be ViewModelStoreOwner with own ViewModelStore. Then throw everything into single FragmentManagerViewModel-like ViewModel that we will register once in activity integration point.

Anyway in both variants we have another problem – we change DI flow. We usually pass all dependencies into Node ready to use, but here we have to instantiate ViewModel inside Node, comparing to everything else that is done outside. Not like a bad thing, something that I want to come to later.

IMHO it should be implemented in the same way as in Fragment – each Node should be ViewModelStoreOwner with own ViewModelStore. Then throw everything into single FragmentManagerViewModel-like ViewModel that we will register once in activity integration point.

Anyway in both variants we have another problem – we change DI flow. We usually pass all dependencies into Node ready to use, but here we have to instantiate ViewModel inside Node, comparing to everything else that is done outside. Not like a bad thing, something that I want to come to later.

This is what we're doing internally right now. I've published a sample demonstrating this

IMHO it should be implemented in the same way as in Fragment – each Node should be ViewModelStoreOwner with own ViewModelStore. Then throw everything into single FragmentManagerViewModel-like ViewModel that we will register once in activity integration point.

Anyway in both variants we have another problem – we change DI flow. We usually pass all dependencies into Node ready to use, but here we have to instantiate ViewModel inside Node, comparing to everything else that is done outside. Not like a bad thing, something that I want to come to later.

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.

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