movie-details.api.MovieDetailsEntry.kt

import androidx.navigation.NavType
import androidx.navigation.compose.navArgument

abstract class MovieDetailsEntry : AggregateFeatureEntry {

    final override val featureRoute = "movie-details?movieId={movieId}"

    final override val arguments = listOf(
        navArgument("movieId") {
            type = NavType.IntType
        }
    )

    fun destination(movieId: Int): String =
        "movie-details?movieId=$movieId"
}

Hi, Thanks for your comment!

It is a good practice to use navigation strings as resources or constants, I definitely agree!

However, in FeatureEntry classes, we can omit this approach as these strings won't be used outside. We can just define as many destination functions as we want, so the end-user will use them instead of raw strings. For example: myProfileDestination, userProfileDestination.
Also, I did not use resources/constants in gists for the sake of demonstration in the blog post (it's easier to get the idea when the reader is not distracted with additional constants).

Nevertheless, strings can be replaced with constants/resources when defining nested navigation graphs in feature-impl modules (if using a setup described in the blog post). I think the approach there would not differ from apps without modularization.

I would suggest exploring this post, which can give you ideas of how this can be implemented: https://medium.com/google-developer-experts/78c78d365c6a

I hope it helps!