How can I navigate from the VM in jetpack compose?...

# compose

[Jason Ankers]

How can I navigate from the VM in jetpack compose? say I’ve fetched some data and I need to navigate after the data has been retrieved

[Jason Ankers]

I ( think) I solved this by navigating inside my composable instead. My button onClick launches a coroutine tied to the lifecycle of my composable, calls viewModel.fetchData(), and then navigates after it’s complete. Is there anything wrong doing it this way?

[Kshitij Patil]

What if fetch fails ?

[Jason Ankers]

I have a try/catch in the button onClick - will that not work?

[Kshitij Patil]

Mixing UI with business logic 😬

IMO either you should have some "Result" Sealed class which you can observe in Composables. If you feel keeping these things separate is complicated, you can have your viewmodel return a Flow of "Result" states and you can collect that in composable scope

Usually I maintain a sealed class of Loading, Success/Content, Error & Undefined states

[Jason Ankers]

Yes, I find that approach to be much more complicated, and I’ve struggled to find a clear example which I can follow where it’s implemented the way you describe. Aside from “mixing UI with business logic” being non-idiomatic in Android dev - it’s very common to do this in React which I’m used to. In this case, my UI is simply forwarding the call the to the VM, so the only business logic is the navigation logic, can you elaborate on what exactly is the issue with doing this?

[Kshitij Patil]

I'd say there'll be some personal bias but depending upon your use case, let's say you've to manage multiple UI components based on the state of VM call you made, like disabling some buttons in loading state, showing progress bar, adjusting visibility of some component, showing error text and what not will be difficult to manage with simple try-catch. And handling backenf errors at UI side at first seems non-idiomatic for me, just sharing my opinion.

[Jason Ankers]

You could still handle errors on the VM side by try/catching, and then re-throwing to prevent navigation in the view. I’m not opposed to implementing an observable navigation event approach, I just couldn’t find any examples of how to do it in compose

[Kshitij Patil]

Let's say you want to make same fetch call in 5 different Composables, is it better to handle errors at one place or 5 places? Also, you don't need to re-throw exception, you can emit an error state instead, with nice error message (string or string-resource)

[Jason Ankers]

I agree, In the rare scenario I’d be making that many of the same fetch-and-navigate calls across different composables, maybe it’s worth investing in a generalised navigation event system. I’d wager that scenario is so rare that it’s probably not worth the added complexity of introducing navigation events (yet)