One Off the Slack: State, Events, and Navigation
Tiago Nunes asked:
Hey everyone, how do I send a one-time event from the viewmodel to the composable? I want to navigate after a long operation
Part of the challenge is being “in the wrong frame” in the question.
In every UI system that I have ever seen, in the end, “what screen am I on?” is part of state, and events that change what screen that is showing creates a change in state. The problem is that too many UI systems hide that state and offer an API that is rather event-centric. This includes Android’s activity-and-fragments system, where the API is expressed in terms of events (“start an activity”, “replace a fragment”, “navigate to a destination”). So, we wind up thinking in terms of events affecting some “black box”, and we wind up tying ourselves in knots trying to figure out how to ensure that we are idempotent and that our event winds up changing our state correctly.
As the thread evolved, Tiago expressed concern about composables knowing stuff about navigation. Nelson Glauber countered:
My navigation logic is not in my composable 🙂 I keep it in the NavGraph. I just pass lambdas/callbacks to my composables. 😉
Google’s Manuel Vivo then chimed in:
Hi 👋 What are you using for navigation? Are you using the Navigation component? What about passing the
navControlleras a dependency to the ViewModel so that the VM can handle the event instead of sending it to the composable?
…you can make the ViewModel be the source of truth for the
navControllerinstead of a composable. There’s nothing wrong with that
We’re coming up with guidance for events in Android. But it’s taking longer than expected. So far, the rules of thumb we have are:
- Let the ViewModel handle the event whenever it’s possible, and
- If the event is critical for the screen, model it as state
With Compose, #1 is possible because the Navigation component hoists its state via
navController. This is something that’s not possible with the View system where the navigation state is a black box inside the
If we’re talking about Compose specifically, I think it’s safe to say that the state holder (that could be a ViewModel) should process the events and make state changes to reflect that on the UI.
i.e. do you need to show a snackbar? The state holder can take be the [source of truth] for the
snackbarHostState, and call
showSnackbarwhen needed. The same pattern applies for
Colton Idle asked:
Do you think any of the compose sample apps do a good job at showing how navigation should be done in a pure compose app? I’m still hung up on how an app with a login screen would work + de authenciation would kick them out of the app.
You have to bear with us 🙂 this is also very new to us and we’re experimenting. In fact, I think there are only a couple of samples that use Compose Navigation. So I agree we need to cover more ground here
Colton then fretted a bit:
Passing navController to VM? I wonder if that keeps the AAC VM testable. Makes sense at a high level to me. But boy oh boy. Do we need more docs around this IMO.
Manuel was less worried:
Yeah, the VM is also testable because it takes the other hoisted states (e.g.
snackbarHostState) as dependencies so you can assert interactions with them and even fake them if needed
Part of the concern here is that Navigation for Compose is an Android-specific library, and not everyone is targeting Android alone, such as Tiago:
We’re also using KMM, but we’re not sharing the VM (yet). If we share the VM at some point, we might need to find another solution (because there might not be a way to supply the VM with a “navController” in the iOS side). In this use case, having a “dumb” VM sounds best. Of course this is out of scope, but still something to consider 🙂
Ideally in iOS, you should also be able to hoist the navigation state. If that’s the case, you could hide the differences between the Android and iOS implementations under an interface, and let your state holder take that instead
I’m purposely using state holder instead of VMs because the latter is an implementation detail IMO