For Compose Navigation, the docs say you should create a `NavGraphBuilder` extension for each screen...

# compose

[Marcin Wisniowski]

For Compose Navigation, the docs say you should create a NavGraphBuilder extension for each screen: https://developer.android.com/guide/navigation/design/type-safety#split-navigation
But in the JetNews sample, they instead create Route composables like this: https://github.com/android/compose-samples/blob/main/JetNews/app/src/main/java/com/example/jetnews/ui/interests/InterestsRoute.kt

Which one is the actual recommendation?

[Stylianos Gakis]

Well then this would make the place where your NavHost is blow up completely in case you start adding more screens.
I think the recommendation still stands, but when you got 2 screens for the entire app, maybe no need to do something like this. Now imagine this last link, but if all of those screens were handled inline in the same file (And this is just 1 of the graphs).

[Jonas]

I think based on your needs (complexity of your app) you could even do both.
We do it like like JetSnack (your second link). (just a related post which describes our current setup)
But we also see our navgraphs, even while split into multiple nested graphs, grow in complexity and length.
I might have another look at your first link in a bit to also incorporate these practices.
In general I feel your Route should not know anything about your nav library. So only applying the first recommendation seems too much coupling for me.