Try out Compose Destinations library

[kasem-sm]

Ref - https://github.com/raamcosta/compose-destinations

[rvenky125]

I'm willing to try this out, if you haven't started it yet

[kasem-sm]

I'm willing to try this out, if you haven't started it yet

yes, you can try. Thank You! 😃

[rvenky125]

I did a little bit workaround on it. But the library requires compose version of 1.1 or 1.2

[kasem-sm]

I see. If the library provides significant benefits over the official compose navigation library, I think we should downgrade the compose version.

[rvenky125]

I agree, let me know if I can help you in downgrading the compose version.

[kasem-sm]

Please create a fork and downgrade the compose version in order to try the Compose Destination library. Looking forward for your code contribution to this repo.

[rvenky125]

Okay, I'm very excited for my first contribution. It'll take time because of my tight schedule. But I'll try to do it every day. Thank you.

[kasem-sm]

No issues. Don't hesitate to connect with me if you need any help with the implementation. Good Luck!

[rvenky125]

Hello @kasem-sm. You have passed functions for the navigation among the screens. It'll be easier if we declare those functions in the specific screen bypassing the nav controller. Is there any strong reason to not doing like that? Now I'm willing to do that. Are ok with that?

[kasem-sm]

Hi. I wanted to have the project scalable. I guess the compose destination library has its own wrapper around nav controller. Imagine replacing the parameters at 10 or more different screen just because you swapped out a library. In future if you shifted to KMM and want to use Decompose library for navigation or any other, it would be just easy to change things at one file or one module rather than 10 different modules.
This is my personal opinion and I may not be right. If you think there is some other way, please let me know :)

[rvenky125]

Yeah, you are right. I can achieve your requirement by providing dependencies through the NavHost to each module. But still using the route(string) for navigation is not sense. So instead of using the route as a param for those lambda functions, we can pass an object of the destination sealed class you have created. Instead of having the route in the sealed class we can use the auto generated Direction object. Now we can define our navigation functions in the app module. If we are going to change to any navigation library we will just change the sealed class(Destination) and the navigation functions in NavHost.

[kasem-sm]

Sounds like it's a good plan. You can proceed with it as this project is open to new ideas.