https://kotlinlang.org logo
#koin-contributors
Title
# koin-contributors
a

arnaud.giuliani

10/21/2021, 2:05 PM
Just made
koinNavGraphViewModel()
function to scope a ViewModel to a given Nav Graph
@Nacho Ruiz Martin it will be ok for Koin 3.1.3
I will integrate your sample in the koin android sample app 👍
n

Nacho Ruiz Martin

10/21/2021, 2:09 PM
Awesome, man. Thanks for that!
a

arnaud.giuliani

10/22/2021, 9:02 AM
thanks for your help
🙇 1
n

Nacho Ruiz Martin

10/28/2021, 3:17 PM
Hey, @arnaud.giuliani man! 👋 I don’t know if you’re aware, but this is not compatible with the current way to use Nav Graphs in Compose. When using Compose, you don’t have
.xml
graph files, nor graph IDs. I have a proposal for a modification of the current
getViewModel
Composable function to be able to pass the
ViewModelStoreOwner
. Since
NavBackStackEntry
implements the interface (doc) it would be easy to use. You can see the proposal in this gist: https://gist.github.com/iruizmar/e15c89e6cbe868f3633facbd4cd313cc ⚠️ It’s not tested in depth, this is just a draft proposal.
a

arnaud.giuliani

10/29/2021, 10:30 AM
you mean, opening to have
viewModelStoreOwner: ViewModelStoreOwner = LocalViewModelStoreOwner.current!!,
inside the
getViewModel
?
n

Nacho Ruiz Martin

10/29/2021, 10:31 AM
Yes 🙂 That’s the exact change. As you can see, you can then provide a different
ViewModelStoreOwner
such as a
NavBackStackEntry
and the
ViewModel
scope will be attached to that one.
That’s really useful to scope it to a subgraph in compose, which is basically represented as a
NavBackStackEntry
. Here’s how Hilt is doing it (similar way): https://developer.android.com/jetpack/compose/libraries?#hilt-navigation
🤔 Maybe I could apply this to the sample I sent you for you to see it in action?
@arnaud.giuliani 👋 I updated the toy app with this new usage. Maybe this way, it will clarify the needing. https://github.com/iruizmar/koin-nav-compose-toy/commit/488122ff103fc2e879a03516476535e0b46c32b7
a

arnaud.giuliani

11/04/2021, 5:59 PM
great, let me check 👍
we could squash usage of `
Copy code
val parentEntry = remember {
                    navController.getBackStackEntry("bc")
                }
                ScreenB(
                    viewModel = getViewModel(parentEntry),
                    navigateToA = { navController.navigate("a") },
                    navigateToC =  { navController.navigate("c") }
                )
to something like
getNavGraphViewModel("bc")
directly
n

Nacho Ruiz Martin

11/04/2021, 7:23 PM
You'd need the NavController inside the
getNavGraphViewModel
for that, though.
a

arnaud.giuliani

11/05/2021, 9:09 AM
yes, we could do that inside
n

Nacho Ruiz Martin

11/05/2021, 9:11 AM
I don’t understand where will we get the NavController from. It should be provided from the root of the NavGraph. So the API would look like:
getNavGraphViewModel("bc", navController)
Is that good enough?
a

arnaud.giuliani

11/05/2021, 10:39 AM
I see, you need to have your navController on your side. Let me check again 🤔
👍 1
then it’s working with the current ViewModel API then?
n

Nacho Ruiz Martin

11/10/2021, 4:11 PM
It is working if you want to have a ViewModel scoped to a single destination of the graph, for example like ViewModelA in the toy app: line. But if you want to have a ViewModel scoped to a subgraph, for example ViewModelBC that should be scoped to the graph with route “bc” in the toy app it’s not working. And it is not working because the current API always gets the ViewModelOwner from
LocalViewModelStoreOwner.current
which happens to be the current destination on the graph. So if you use the current API from composableB, you’ll get a ViewModel that will live while you are inside that destination. You can’t have a ViewModel attached to a subgraph (shared between B and C, in other words). And that is what fixes my approach, by letting the user to provide it with a different owner, in this case:
navController.getBackStackEntry("bc")
a

arnaud.giuliani

11/10/2021, 5:09 PM
yes, need to allow to use the right store 🤔
n

Nacho Ruiz Martin

11/11/2021, 11:55 AM
I can open a PR with the little change on the Composable
getViewModel
, is that OK?
a

arnaud.giuliani

11/12/2021, 8:25 AM
I’ve pushed this - d77fcc482126b79d943ea11ddf5befa2369ef0bb
tell me what you think 👍
n

Nacho Ruiz Martin

11/12/2021, 8:57 AM
Awesome 💪
Hey @arnaud.giuliani! Sorry to come back with this topic again, but currently, 3.1.4's
getViewModel
expects a
ViewModelOwner
and Navigation’s
NavStackEntry
are actually `ViewModelStoreOwner`s . This makes the way to use the API uglier, like this:
Copy code
getViewModel(owner = ViewModelOwner.from(parentEntry))
I don’t know the real difference between
ViewModelOwner
and
ViewModelStoreOwner
. Is there any reason for you to be using the first one?
a

arnaud.giuliani

12/02/2021, 8:58 AM
ViewModelOwner is more there to let choose ViewModelStoreOwner or RegistryOwner
let see how to simplify then
n

Nacho Ruiz Martin

12/04/2021, 1:10 PM
A simple overload of the
getViewModel
method would suffice. If you provide a
ViewModelStoreOwner
then Koin will use
ViewModelOwner.from
to get a
ViewModelOwner
. WDYT?
a

arnaud.giuliani

12/06/2021, 9:07 AM
yes, was thinking about something like that yes
I will make a PR. I’ll ping you
137 Views