Question around deep link parameters involving enums about navigation-compose-typed HOT 5 OPEN

My POV: any serious deep-linking should be separate from the navigation stack, i.e. have a separate URL parser that constructs the destination and then navigates "programmatically".

Anyway, I'll accept a PR using a name instead of an ordinal, though the issue stays - it's kind of implementation detail.

from navigation-compose-typed.

I'll accept a PR using a name instead of an ordinal, though the issue stays - it's kind of implementation detail.

I was thinking about this change a few days ago - but my motivation was clarity when debugging (we send those navigation urls to Sentry as breadcrumbs)

from navigation-compose-typed.

have a separate URL parser that constructs the destination and then navigates "programmatically".

Not 100% sure I follow here. Could you elaborate a bit on this? I do like the fact that androidx.navigation kinda handles everything for you normally even for deep links, as long as they are constructed well, with the right parameter names etc.
Is whatever you've done here to fix this issue instead also something that you could share? I'm quite curious.

And changing it to the name even for debugging purposes is interesting, so I do wonder if and how many people may have been relying on the existing behavior with the numbers where such a bump would break them. And if so, what could they do to keep this working again?

from navigation-compose-typed.

Kiwi.com motivations having it handled externally are:

1. Handling BCs, preprocessing, etc.
2. Historical reasons - we are not 100% navigation composed.
3. Some additional logic (landing to a splash activity that redirects to other activities).

Also, I like the concise nav-graph definition and expanding the def with deeplinks is quite making the hierarchy less readable.

I do wonder if and how many people may have been relying on the existing behavior with the numbers where such a bump would break them. And if so, what could they do to keep this working again?

TBH no idea here - I even don't know how exactly that works as I have never used it.

from navigation-compose-typed.

I see yeah, different requirements indeed.
Just to give you some context on how we have been using this is that you use this library normally, and define your route like this, where the screen is this and the deeplink is this and all this works perfectly fine since there are no arguments or whatever involved, simple.

Where they are involved, it's the same setup, but what I had done is try to kinda go backwards from what this library generates as a route for a destination, taking into consideration how some things are optional arguments, some go in the path etc, and then write the route myself adding the right name from the parameter name, with the line
override val uriPattern: String = "$baseDeepLinkDomain/chat?$chatContextParameterName={$chatContextParameterName}" in this draft PR where I was looking into this.

But I see your point as to how this library is not necessarily 100% focused on making that part work. If you have any more thoughts on this I'd love to hear them, if not I will see if I can come up with something better for ourselves, and share it here. Otherwise I might just do this manual work as I show in that draft PR and go from there 😊

from navigation-compose-typed.