What is the benefit of using `Router` vs `Navigati...

# compose

[ahulyk]

What is the benefit of using Router vs Navigation Components ?

[gpaligot]

Navigation Components isn't compatible with compose yet

[Melvin Biamont]

https://medium.com/@alizee.camarasa/how-do-we-navigate-in-aircalls-android-app-f2160f7c3f4b

[ahulyk]

what about that:
Compose onClick() -> ViewModel.handleClick() -> Fragment.navController.navigate()

[Zsolt]

If you're referring to Router from compose-router, I can comment on why I think it's useful, but your mileage may vary. 

For one, It allows you to stay completely in Compose world. You don't need more than a single Activity as an entry point. You don't need Fragments. In a sense, this makes your tech stack thinner, and you can avoid some misery with Intents, flags, obscure back stack operations, transactions, and a lot of things you otherwise can only learn the hard way. 

With a Router approach, back stack is just a list of simple objects, and you can easily write your own list operations. Boom, done. Plus you can pass data directly between layers with full compile-time safety, no need for Intents.

Also, with a Router you can represent logical state switching (logged out / logged in), screen switching, sub-screen switching (view pager) with the same lightweight pattern. Again, fewer things to learn the quirks of, and a simple and universal tool / pattern to achieve more things.

Local navigation: this is a huge benefit if you have any kind of shared modules between multiple apps. And even if you don't, it's a much simpler solution to navigation problems. With a top-level Navigator approach you run into the issue that Navigator has application-specific navigation operations. But a shared module cannot know anything about those, because they may vary between different apps. You can approach it from the other side, and it's still bad: instead of defining what navigation operations you offer, you could satisfy the navigation dependencies of the shared modules by some top-level wiring. This requires constant maintenance, and works only as long as you reuse shared modules 1 level deep. Any module deeper down could change as an implementation detail of the level above, and now the top-level app is broken. Contrary to this, a Router approach allows you to implement navigation as a local concern of the module you are writing. All the above issues are boom, gone.

Granularity: Activities mean a full screen. Fragments can mean smaller parts, but I haven't really seen an example of leveraging this down to the level of what's achievable with Compose. With Compose you could introduce a Router at any level in the tree, helping you to organise it in much thinner layers.

Downside: you probably don't want to go full Compose on an existing, large codebase, as it's almost equivalent to rewriting it from scratch. But if I'd start a new app today imagining that Compose is production ready, I'd not hesitate to leave Activities, Fragments far behind, and go full Compose.

[Leland Richardson [G]]

i pretty much agree with @Zsolt’s analysis here…. though I’ll add that navigation runs deep and there are benefits to using a solution that has been “hardened” for a lot of the more subtle use cases and corner cases that navigation has. Also that someone familiar with the navigation arch component should be able to get it working with compose even without using Fragments etc., and then you’d get the best of both worlds for the points above. If you did so and ran into trouble, i’d be very interested in understanding where you ran into trouble as it might be an indication of an API that Navigation AAC needs to add.

[Leland Richardson [G]]

but it’s also cool to see things like the router pop up in the compose ecosystem (especially so early) and i’m really interested to see whether something like this is what people gravitate towards or not

[Ryan Mentley]

I think "shouldn’t be able" is supposed to be "should be able" - we had some experiments about what it might look like

[Leland Richardson [G]]

yes, sorry, i meant “should be able to”