Just went through navigation-compose samples and have rather silly doubt: in sealed class for Screens, why can't we just have computed property called "route" which will call

stringResource(resId)

in its

get()

method

The first thing I did was create my own

navigate

extension and use my own Route

enum class

as route argument

@Javier do you just have a single level of navigation? Or do further levels down have their own `enum class FooRoute`s?

Until now just one level, but I have to experiment with multiple levels and multiple nav graphs

I think one benefit I found with sealed classes was that I could provide functions for a screen for just the value of the argument. So the caller didn't need to know the key for it.

Did you use some mechanism to autogenerate the route string?

lol, this:

sealed class Screen(val route: String) {
 object Dashboard : Screen("Dashboard") {
   val routeWithArg: String = "$route?arg={arg}"
   fun withArg(arg: String): String = routeWithArg.replace("{arg}", arg)
 }
}

I am trying with

simpleName

(impossible because you can get duplicated routes) and

qualified

of

jvmName

have the entire file, and I think there is an open issue about

sealed classes

where you can extend a sealed class from a different file and this, maybe, can have problems

Don't want to detail the thread, but I'm curious what value you're getting out of the jetpack navigation library if you're not using it for backstack management and just have a simple enum/sealed class defining your screens. Is it just transitions? It seems to me like backstack management and transitions are the two main value props of using the navigation library with compose.

FWIW, route names absolutely should never be translatable strings (they don't change as the user's language changes). That's why they're separate things

@Zach Klippenstein (he/him) [MOD] what do you mean by this?

if you're not using it for backstack management

navigation-compose

does support the backstack management right?

i’m not convinced you need a whole library to write

myBackstack += newScreen

,

myBackstack.dropLast()

Because if your sealed class has nested sealed classes you can have multiple objects or classes with the same simpleName

@Javier is there any example of using

navigation-compose

for nested graphs? was just curious how we need to deal with those scenarios. I'm aware of the one by @ Afzal Najam

Sample

@Zach Klippenstein (he/him) [MOD] but since we're already getting away from the fragments, I thought we need something to support those jetpack navigation functionalities (backstack, safeargs, deeplinks, etc.) in compose

Currently there is no safe args with compose, so I don't know if we should just go for deep links all the time or there is some benefit using "the normal approach"

I don't think we have an example of nested graphs, but the DSL already supports the

navigation

element for nested graphs. We could certainly add an overload of that which lets you define it with a route (rather than an int ID as is required in the base Navigation DSL)

@Kshitij Patil If this library is a good fit for you, then don’t mind me 😅 All i was trying to say is that Compose allows for navigation idioms which wouldn’t be possible, or at least easy, in classic Android, and you might not need the full power of this library, and all the “magic” it brings along. E.g. a backstack is just a stack, and can be implemented with a basic kotlin List. Safeargs is solving a problem that is specific to this library in the first place – e.g. if you use a sealed class for your routes + args, they’re already strongly typed. Deep linking depends on your use case.