Just went through navigation-compose <samples> and have rather silly doubt: in sealed class for Scr...

# compose

[Kshitij Patil]

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

[Javier]

The first thing I did was create my own navigate extension and use my own Route enum class as route argument

[Zach Klippenstein (he/him) [MOD]]

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

[Javier]

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

[Javier]

Maybe I have to move from enum to sealed 🤔 but if a destination is shared two screens...?, I have to think about this when I "crash" with those use cases

[Javier]

@Zach Klippenstein (he/him) [MOD] did you have modeled something like this when you developed your own navigation library?

[Javier]

The easiest thing of the enum is I can use its name as string, and it is unique, if I move to a sealed class maybe I had to add a required Id and I have to set manually which add more boilerplate

[Afzal Najam]

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.

[Javier]

Did you use some mechanism to autogenerate the route string?

[Afzal Najam]

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)
 }
}

[Javier]

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

[Zach Klippenstein (he/him) [MOD]]

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.

[Zach Klippenstein (he/him) [MOD]]

did you have modeled something like this when you developed your own navigation library?

Not sure exactly what you’re referring to. compose-backstack tries to do as little as possible, the only reason it even has a backstack at all (in contrast to something like Crossfade, which only takes the “current” screen key) is to figure out whether a forward or backward transition animation should be shown.

[Ian Lake]

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

[Kshitij Patil]

@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?

[Kshitij Patil]

@Javier could you please explain a bit why javaclass.simpleName won't work?

[Zach Klippenstein (he/him) [MOD]]

i’m not convinced you need a whole library to write myBackstack += newScreen, myBackstack.dropLast()

[Zach Klippenstein (he/him) [MOD]]

especially because it forces you to manipulate your backstack as a list, and maybe your navigation itself is declarative and not a series of push/pop calls

[Javier]

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

[Kshitij Patil]

@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

[Javier]

Sample

[Javier]

About an example with nested graph I don't know if there was one in Gerrit samples, maybe @Ian Lake can help us

[Kshitij Patil]

@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

[Javier]

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"

[Ian Lake]

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)

[Ian Lake]

Definitely feel free to file feature requests as you find them (this is only alpha01, after all): https://issuetracker.google.com/issues/new?component=409828&amp;template=1093757

[Zach Klippenstein (he/him) [MOD]]

@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.