Is there already a way to scope view models by composable?

# compose

[Tgo1014]

Is there already a way to scope view models by composable?

[Adam Powell]

short answer: yes.
longer answer: what specific scoping behavior do you want, what code do you want to be able to write?

[Tgo1014]

Let’s say I’ve a pager with the same composable and each needs their own instance of the same viewmodel. How would I do that?

[Adam Powell]

have each of your pages provide LocalViewModelStoreOwner and multiplex them into a host viewmodel; this is how androidx navigation-compose does it

[Adam Powell]

you'll have some decisions to make around the intended lifecycle of those viewmodels, how long to keep them alive and when to clear them if you don't keep all of the pager's pages composed at the same time

[Tgo1014]

so it requires some work I see, I’ll have to create some custom implementation of LocalViewModelStoreOwner right? I need to check how the navigation does it then

[Adam Powell]

a little work, but not too much. the usual way to think about this is to have the composable function that provides the LocalViewModelStoreOwner fetch a container ViewModel that you write for this purpose. Then use a RememberObserver to remove+clear the ViewModelStore when a page leaves the composition if the host activity isChangingConfiguration isn't true

[Adam Powell]

(since if you're tearing down the composition for a config change you want to leave them alone)

[Adam Powell]

the reason to use RememberObserver directly instead of DisposableEffect is because you need to hook onAbandoned too; ViewModels are created during composition and need to be cleaned up if the composition they were created in doesn't commit

[Adam Powell]

shouldn't be more than ~70-100 lines of utility code that you write once and don't have to look at again 🙂

[Tgo1014]

Very detailed reply, thanks for the help Adam! 😄

[Adam Powell]

you're welcome; I was just doing this recently for a personal project a couple weeks ago so it was fresh 😄

[Tgo1014]

Do you think in the future it could be included directly on hilt ? Like specifying some key would get another view model and all calls for the same key would return the same? Is this even possible? haha

[Adam Powell]

I'm not quite sure I understand the question or the relation to hilt; this is lower-level than hilt and you don't need hilt to do it

[julioromano]

have each of your pages provide LocalViewModelStoreOwner and multiplex them *into a host viewmodel*; this is how androidx navigation-compose does it

@Adam Powell (I think I have an English problem here) can you explain with different words what do you mean by “multiplex them into a host viewmodel” ? Thanks!

[Adam Powell]

my apologies; you have a point where you need to create one ViewModelStore per page, each one establishes a namespace and scope for viewmodels obtained beneath it. You need a place to store those `ViewModelStore`s and make sure they're retained. Using another ViewModel is the most straightforward way to do this since it already provides all of the facilities and guarantees you want. You'll create your own ViewModel that stores a map of some key that is unique for each page to a ViewModelStore, and you'll need to manage the addition and removal of these `ViewModelStore`s from that map. Then you'll need to provide the correct ViewModelStore via LocalViewModelStoreOwner to the content of each page.