Why split api and impl module in all feature modules? Is there a better solution?

[Jaehwa-Noh]

It is as though generating boilerplate code in all feature modules.

I suggest that making a core:route module that contains all route data classes, and all feature modules have dependency to core:route module.

I think this approach doesn't need to split api and impl module in feature modules.

What do you think about my approach?
@dturner and everyone in here?

[SimonMarquis]

I suggest that making a core:route module that contains all route data classes, and all feature modules have dependency to core:route module.

This will create a bottleneck that we want to avoid, especially in large multi-module codebases. Specifically, every time you will change/add/remove a route, almost the entire project will get invalidated because all features depend on this central :core:route module.

Having api/impl split allows us to only invalidate impacted modules.

[Jaehwa-Noh]

I also considered it, but we don't change routes very often times, aren't we?

[SimonMarquis]

Not in this project, but I feel like this is meant to be a showcase of best practices, and module isolation (separation of concerns) becomes quite important as projects (and teams) grow.

[dturner]

Exactly right @SimonMarquis. Feature teams should be responsible for their own routes and not have to update a shared module with all the downsides that shared ownership brings.

[Jaehwa-Noh]

Another suggestions, the reason of split api and implementation is to use key in the entryProvider where is implemented in each feature modules, why don't we hoist that onClick event or etc event to the app module which knows all keys already?

[dturner]

Because then you place the responsibility of navigating between feature modules on the app module. I talked about this here: https://youtu.be/6L6GfvlmKj8?si=cXPZTyj0AsOnfAhJ&t=561

[Jaehwa-Noh]

You concern the getting bigger responsibility of :app module that manage feature Navigations.
This is good to reduce the :app module responsibility, but :feature modules add the navigation implementation for just on extension function, and still :app knows all the navKeys.

What about just split the Navigation responsibility from :app to new module such as :navigation?
All extension model where in features move in :navigation.

// in the `:navigation` module.

fun EntryProviderScope<NavKey>.forYouEntry(navigator: Navigator) {
    entry<ForYouNavKey> {
        ForYouScreen(
            onTopicClick = navigator::navigateToTopic,
        )
    }
}

fun EntryProviderScope<NavKey>.bookmarksEntry(navigator: Navigator) {...}
fun EntryProviderScope<NavKey>.interestsEntry(navigator: Navigator) {...}
...

Then dependency would be :app <- :navigation <- :feature(doesn't need split api and impl)
I think it would be possible because of just pass navigator to extension functions.

[Jaehwa-Noh]

I create PR at #2046 that address this comment #2009 (reply in thread)

[SimonMarquis]

This means that all features will be invalidated as soon as you introduce a new one (or even simply add an argument to an already existing navigation entry). This is specifically what the api/impl split avoids.
This project is currently not fully migrated (we could say), because EntryProviders are currently registered explicitly by the app module instead of delegating this aggregation to the dependency framework.