Style Guide / Docs advice for partially shared lazy feature modules

📚 Docs or angular.io bug report

Description

The docs / style guide should provide a guide / example for partially shared lazy feature modules.

At the moment there’s only the Sharing Modules guide for “commonly used directives, pipes, and components”. But there should be another guide that focuses on sharing “uncommenly used components”. (Or: “lazy loaded modules that depend on some components of other lazy loaded modules”)

Example 1:

I have an enterprise application with lot’s of modules, which are all lazy loaded. But some of these modules use a few components and services of other modules.

app/
    module1/
        components/
            M1Component1
            M1Component2 <-- uses M1Component1 internally. no problem because it's the same module

    module2/
            M2Component1 <-- uses M1Component1 internally

What’s the best way to solve this? Putting these components into SharedModule isn’t an option, because those components aren’t “commonly used”. And importing the whole Module1 into Module2 isn’t an either, because I only need a few components from Module1.

Example 2:

The application has a DashboardModule which uses InjectionToken and Providers to register WidgetComponents from other modules. Those Providers must be registered at application start (or when the DashboardModule gets loaded). In other words: The DashboardModule doesn’t know any widgets by itself. All widgets are provided by the other modules. But all those modules are lazy loaded.

app/
    dashboard/
        services/
            DashboardWidgetTypeService <-- with @Inject(DASHBOARD_WIDGET) widgets

    module1/ <-- provides M1DashboardComponent as DASHBOARD_WIDGET
        components/
            M1DashboardComponent

    module2/ <-- provides M2DashboardComponent as DASHBOARD_WIDGET
        components/
            M2DashboardComponent

Current Solution:

At the moment each module consists of 2 modules: a SharedFeatureModule and a FeatureModule. And the AppModule imports all those SharedFeatureModules.

app/
    module1/
        MyFeature1Module <-- imports MyFeature1RoutingModule and MyFeature1SharedModule
        MyFeature1RoutingModule
        MyFeature1SharedModule <-- has forRoot method to register Dashboard providers

    module2/
        MyFeature2Module <-- imports MyFeature2RoutingModule and MyFeature2SharedModule and MyFeature1SharedModule
        MyFeature2RoutingModule
        MyFeature2SharedModule <-- has forRoot method to register Dashboard providers

    AppModule <-- imports MyFeature1SharedModule.forRoot() and MyFeature2SharedModule.forRoot()

The AppModule imports all SharedFeatureModules via forRoot() to register the dashboard widget providers.

I’m not yet sure what’s the “best practice” for this. But I’m sure you’ll have some good advice.

[yelhouti]

This question has been asked in many place and no good answer had been provided yet. This clearly missing from docs. Linking a stackoverflow question (for google to point people here once answer is available) https://stackoverflow.com/questions/39648119/importing-a-component-from-a-lazy-loaded-module-into-another-lazy-loaded-module

[benneq]

The question is suited for github, because it should result in an improvement for the docs.

For the second part it doesn’t really matter if it’s an InjectionToken or if I call a Service. The point is: The registration must be done when the application starts. But the registration is also part of a (lazy) feature module and uses a few components from that (lazy) module.

This means: AppModule must import the “shared part” of the feature module, because there’s no other way to eagerly register providers (or call a service) when the feature module is lazy loaded. The “shared part” includes the registration process (injection token or service call) of the widget, plus the widget component, and all other needed components for the widget.