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.

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