Hello :wave: I’ve been reading some articles about navigation component with compose, such as the o...

# compose

[Nacho Ruiz Martin]

Hello 👋

I’ve been reading some articles about navigation component with compose, such as the one from Joe Birch about modular navigation and the one from Jossi Wolf.
Both are pretty great and solve the problem quite good.

Still, I have some doubts about how to reuse screens or screen flows in this kid of approaches. Does it make sense to duplicate the screens that you want to reuse in the nav graph with different routes to have different navigation callbacks?

For example, you have an account modification screen that you want to use both in sign up and in the account section of the app.

[K Merle]

I'd probably reuse screen only in a case both situations require same screen (including callbacks, api calls etc..), else I wouldn't couple authentication and edit account screen in this way.

[Nacho Ruiz Martin]

That’s just an example. I really think there are cases in which some screen flows may be shared but with different navigation.

Imagine a permission request screen, or some screen to retrieve data from the user. Those kind of screens surely are susceptible to be inflated on different places. Just like we used to do with old ActivityResult API.

It would be so easy to just provide a different lambda in the screen composable function. I don’t really see why would be better tu duplicate the whole screen and ViewModel logic just because you have a different destiny.

[K Merle]

Possibly those screens in example can have same route. 🙂

[Nacho Ruiz Martin]

And how would you provide them with different navigation lambdas?

[K Merle]

Same screen with different route? I am not sure, possibly would not do that.

[jossiwolf]

Yes, exactly. Hoisting and co-locating navigation allows exactly that. You can re-use the screen composables but declare different routes and configure your nav in your composable's nav lambdas then 🙂
(glad to hear you liked the post!!)

[Nacho Ruiz Martin]

That's brilliant. Thank you Jossi :).

[Nacho Ruiz Martin]

And, yeah, the post was so great! Really detailed :). So thank you for that too.

[Nacho Ruiz Martin]

Btw, sorry to bother, but how would you approach a navigation in response to an event happening in the ViewModel? For example, on response from a server call.
Would you represent that in the state? An events channel? Any other approach?
Thanks 🙇

[jossiwolf]

Cheers!
We expose a navigationEvents Channel (well, now a SharedFlow) from some of our VMs. Navigation is an event that you don't want to be executed more than once while you don't (and shouldn't) have that control over your state. Since our routes are declared separately from any UI code we can also use these from the VM and return them so that the UI can navigate with them.

[Nacho Ruiz Martin]

Sounds great, thank you very much 🙂