Entry Components of a Lazy Loaded NgModule are not available outside the Module

[marvinscharle]

I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[X] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Follow-up issue for #12275 as requested by @DzmitryShylovich

Current behavior
entryComponents of a lazy loaded NgModule cannot be rendered using ComponentFactoryResolver. Error message: No component factory found for {{entryComponent}}

Expected behavior
entryComponents should be available just like if the module is imported

Minimal reproduction of the problem with instructions
http://plnkr.co/edit/9euisYeSNbEFrfzOhhzf?p=preview

I created a simple setup, similar to what we use internally. Main component provides a method to render a Type. EntryComponent is declared as entryComponent in Page1Module. However after having loaded Page1Module, when trying to render EntryComponent via ComponentFactoryResolver, No component factory found for EntryComponent is thrown.

What is the motivation / use case for changing the behavior?
Render entryComponents of child modules at root level. Use cases for this approach are

• Modals that shall be rendered on top of everything
• Notifications
• etc.

Please tell us about your environment:
We're using currently Angular 2.1.1 but this affects the latest version of Angular (2.4.6) as well (see plnkr).

• Language: TypeScript ^2.0.0

[DzmitryShylovich]

After some investigation I figured out that in your in works as designed.
Entry components follow the same rules as providers in lazy loaded modules. https://angular.io/docs/ts/latest/cookbook/ngmodule-faq.html#!#q-lazy-loaded-module-provider-visibility
They are only visible inside lazy loaded module.

[marvinscharle]

Ok, if this is the intended behavior, how can specific tasks like the use cases above be accomplished?

I don't think that blowing up the main module is a proper solution.

[DzmitryShylovich]

If you want to use an entry component in MainComponent then you should provide it in AppModule

[marvinscharle]

So your solution indeed is to move everything into the main module?

IMO this totally breaks the module concept of Angular which should allow to group functionality blocks into one module.

This means basically that things like modals are impossible to use with a lazy load architecture.

[DzmitryShylovich]

You need to use an api similar to material's https://material.angular.io/components/component/dialog
Then it should work

[marvinscharle]

Wow, so your opinion is that we should rather move DOM content, like Angular Material does. See here: https://github.com/angular/material2/blob/master/src/lib/core/portal/dom-portal-host.ts#L30-L55

If this is really the best practice to handle this in Angular, basically we can dump Angular and start using JQuery again.

Sorry, but I cannot take this approach seriously.

[DzmitryShylovich]

I don't know what is the best approach for modals and lazy loading, but anyway in your plunkr it works as intended and there's no angular bug here.
For discussion about modals it's better to use support channels such as gitter and stackoverflow

[marvinscharle]

Ok, in this case I'm changing this issue into a feature request.

IMO these use cases should be handled by Angular itself rather than by moving things along the DOM manually.

[artaommahe]

Faced with same issue today - component for modal defined in lazy loaded module does not handled by app modal service (it cant find it despite entryComponents usage). Forced to move it to main bundle that breaks lazy modules structure and usage logic 😕

[kiwileaks78]

Same issue there ... Impossible to use an entryComponents in a lazyLoaded module without breaking the lazy modules logic : My LazyLoaded module depends on an entryComponent declared in my AppModule :(

[jmcclanahan]

Ran into this same issue, I did come to a resolution though after looking through ng-bootstrap modal source code. Essentially the issue (from my understanding please correct me if I'm wrong) is that your lazy modules are not included in the initial injector when your app is bootstrapped and the initial injector cannot be modified once it is set. Which is why you get the error in the OP. When one of your lazy modules is loaded it gets its own injector with references to whatever you declare or provide in your lazy module. That being said, as long as wherever you create your dynamic component at has reference to the correct injector and componentFactoryResolver you can indeed reference an entryComponent outside of the lazy loaded module.

So, what I did was create a singleton service to store the injector and componentFactoryResolver of the dynamic component I want to create. This service needs to be outside of your lazy modules. Then whenever I go to dynamically create a component I can call this service to get what I need.

Code below will be wherever you are creating your dynamic component outside of your lazy module

@ViewChild('parent', {read: ViewContainerRef}) parent: ViewContainerRef;
  private componentRef: ComponentRef<any>;
...
const childComponent = this.componentFactoryResolver.resolveComponentFactory(yourComponentRef);
this.refInjector = ReflectiveInjector.resolveAndCreate([{provide: yourComponentRef, useValue: yourComponentRef}], this.injector);
this.componentRef = this.parent.createComponent(childComponent, 0, this.refInjector);

<div #parent></div>

Then in your parent component for your entryComponent you'll inject injector and componentFactoryResolver and set their values in the shared service:

constructor(private componentFactoryResolver: ComponentFactoryResolver, private injector: Injector) {}

Let me know if this doesn't make any sense and I can elaborate further. Edit I forgot to mention I'm using Angular 2.4.9.

[gcorgnet]

Thanks @jmcclanahan. Are you able to tell us a bit more about what that service looks like and how it is set up? I am struggling with a similar issue, trying ti dynamically load a component from one lazy loaded module into a component from another lazy-loaded module and even though (I think) I have added the entry components in the right place, I get told I haven't. Thanks

[jmcclanahan]

@gcorgnet - Sure. So my use case was, I have a common toolbar on every page of my app, but within the toolbar I wanted to add buttons and tools for additional functionality based on what page I was on. In order to achieve this I created a component to hold these buttons/tools and their logic and I wanted to keep these components inside of the module they are associated with. So, essentially nothing outside of my module knows anything about these specific toolbar functions while still being able to show them on the common toolbar. Below is my working solution which I hope will help you:

All I'm doing with the toolbar service is creating an observable, so your lazy component can pass it's componentFactoryResolver and injector references to the toolbar common component that is listening for the receiveContext Event.

toolbar.service.ts

@Injectable()
export class ToolbarService {
    contextReceivedSource = new Subject<any>();
    contextReceived$ = this.contextReceivedSource.asObservable();

    receiveContext(componentFactoryResolver: ComponentFactoryResolver, injector: Injector) {
        this.contextReceivedSource.next({ resolver: componentFactoryResolver, injector: injector });
    }
}

In your lazy loaded component you'll want to inject componentFactoryResolver and injector and fire an event in the toolbar service.

lazy loaded toolbar component

...
constructor(private componentFactoryResolver: ComponentFactoryResolver, private injector: Injector) {}
...
ngOnInit() {
  this.toolbarService.receiveContext(this.componentFactoryResolver, this.injector);
}
...

Finally, in my core toolbar component I'm subscribing to the observable in the toolbar service so that anytime an event is fired it will try to inject and create the lazy component that I need. It's also important to destroy the componentRef that you create otherwise you will end up with memory leaks.

...
@ViewChild('toolbarTarget', {read: ViewContainerRef}) toolbarTarget: ViewContainerRef;
component: Type<Component>;
refInjector: ReflectiveInjector;
resolverSub: Subscription;
refInjector: ReflectiveInjector;
componentFactoryResolver: ComponentFactoryResolver;
injector: Injector;

ngOnInit() {
  this.resolverSub = this.toolbarService.contextReceived$.subscribe(resolver => {
      this.componentFactoryResolver = resolver.resolver;
      this.injector = resolver.injector;
    });
}

updateToolbar(data: any) {
    this.clearComponent();
    this.component = data['toolbar'];
    if (this.component) {
      const childComponent = this.componentFactoryResolver.resolveComponentFactory(this.component);
      this.refInjector = ReflectiveInjector
          .resolveAndCreate([{provide: this.component, useValue: this.component}], this.injector);
      this.componentRef = this.toolbarTarget.createComponent(childComponent, 0, this.refInjector);
    }
  }

  clearComponent() {
    this.toolbarTarget.clear();
    if (this.componentRef) { this.componentRef.destroy(); };
  }

  ngOnDestroy() {
    this.resolverSub.unsubscribe();
    this.clearComponent();
  }

Your dynamically created component will then be placed wherever you put the corresponding #toolbarTarget

<div #toolbarTarget></div>

As an aside, I'm using this line this.component = data['toolbar']; in the common toolbar component to get the lazy loaded component reference from the route. If you want to see the full code for this I can post that, but it's outside the scope of this discussion.

{ path: '', component: yourComponent, data: { toolbar: yourToolbarComponentToInject } }

Let me know if you have any further questions!

[Dunos]

@jmcclanahan I have one question (probably a stupid one) about your code, when you mention the "lazy loaded toolbar component", you put the service call code in the ngOnInit section, but how do you manage to initialize it (the component) without having to add it to the HTML code and hide it later in the DOM? Since that component is only going to be used in the topbar, I don't load it anywhere else before.

[jmcclanahan]

@Dunos - I realized I completely left that part out of my example above, sorry about that! You'll want to add the dynamic component as an entryComponent in the lazy loaded module it is associated with.

Then in the toolbar component itself you'll define a ViewContainerRef that will reference the location in your html template where you want the dynamic component to display. Then the updateToolbar() method will take care of creating your component, placing it in the specified location and showing the component on the toolbar.

@ViewChild('toolbarTarget', {read: ViewContainerRef}) toolbarTarget: ViewContainerRef;
...
updateToolbar(data: any) {
    this.clearComponent();
    this.component = data['toolbar'];
    if (this.component) {
      const childComponent = this.componentFactoryResolver.resolveComponentFactory(this.component);
      this.refInjector = ReflectiveInjector
          .resolveAndCreate([{provide: this.component, useValue: this.component}], this.injector);
      this.componentRef = this.toolbarTarget.createComponent(childComponent, 0, this.refInjector);
    }
  }

Your dynamically created component will then be placed wherever you put the corresponding #toolbarTarget

<div #toolbarTarget></div>

The clearComponent() method gets called whenever ngOnDestroy() is run, which takes care of hiding the component when you leave the page.

clearComponent() {
    this.toolbarTarget.clear();
    if (this.componentRef) { this.componentRef.destroy(); };
  }

  ngOnDestroy() {
    this.resolverSub.unsubscribe();
    this.clearComponent();
  }

I've also updated my original post above. I've been getting a lot of questions about this, so I'll add a working example using this dynamic toolbar as soon as I can and update you guys with a link.

[Dunos]

@jmcclanahan that I get (I think), but I still don't understand how the call to the service is make from the dynamic component (the this.toolbarService.receiveContext call part) since the ngOnInit never gets called (or I don't see how to do so). I added to the entryComponents but need to initialize it somewhat to get the onInit to work.

[jmcclanahan]

@Dunos - Maybe an example will be best. Say I'm navigating from the index page of my app to Page A. You will have a corresponding route for Page A, that will define Page A's module/component. Page A will also have a separate component defined that I want to display in the global toolbar. So, inside Page A's main component you will inject ComponentFactoryResolver and Injector and then fire a receiveContext event. This bit of code:

constructor(private componentFactoryResolver: ComponentFactoryResolver, private injector: Injector) {}
...
ngOnInit() {
  this.toolbarService.receiveContext(this.componentFactoryResolver, this.injector);
}

Sorry, I could see how that could be confusing. You don't put that code in the component you want to display in the toolbar, but rather the component associated to the page you are on.

[Dunos]

@jmcclanahan Ah perfect, many thanks!!! Got it working now :)

[pomo-keith]

@jmcclanahan I just solved the same issue before finding this post. One thing I noticed is if you want to save a few characters in your function declarations, you can get a reference to the ComponentFactoryResolver using the Injector that you pass. you can just do:
injector.get(ComponentFactoryResolver);

And that should return the reference you need. But in the end it gives the same result as passing the ComponentFactoryResolver in as a parameter in the function as well.

[renatoaraujoc]

This solves my issue as well.

In sum, all you need to know is that when you want to dynamically create a component that's declared in a lazy module, you need to actually use ComponentFactoryResolver from a component that's declared in that lazy module. The root injector (which contains the root ComponentFactoryResolver) will not know about any entryComponents declared in a loaded lazyModule.

Looks kinda weird, but this is how Angular is designed (which makes sense) but this actually creates extra complexity when working with the framework, imho.

How Angular team could leverage this: Whenever a route is activated, the root injector should append the entryComponents listed on that lazyModule automatically and whenever the route is changed, the previously appended entryComponents should be automatically destroyed, this would ensure less complexity and avoid over flooding the root injector with extra component factories.

I'll submit a feature request for this.

Thank you!

[anapanadero]

Many thanks @jmcclanahan

[rraya]

@jmcclanahan thanks a lot!! @renatoaraujoc have you submitted this feature to Angular team?

[renatoaraujoc]

@rraya I have submitted a feature request regarding this "issue" (it's not really an issue if you think about it), please see #17168.

[ashgibson]

Just to add to this. My use case is that I have created a ModalManagerService in my AppModule which has an open method that all other parts of the app call to open a modal. It gets passed a component which is then opened as a modal. I also have a closeAll method which is used when the modals need to be closed by some action other than the user closing them e.g. route change due to session timeout.

[werts]

@jmcclanahan but I still not understanding yours,many thanks if there are some suggestions.it seems some error occured at 'this.componentFactoryResolver.resolveComponentFactory'

[werts]

@Dunos can u give me a hand?I suffered the same issure for weeks,and its really a headache.

[jxhou]

It looks like that the issue does not exist in Angular 9 any more due to the ivy implementation (tested with 9.0.0-next.7). You can dynamically create a component of a lazy loaded module from outside of the lazy module. It appears to be the case that the entry component declaration is not needed any more for dynamic components in Ivy. Ivy does not need a separated component factory which used to be generated by the compiler. The component factory info is embedded in the component definition with Ivy(?). Once you have a component type, you should be able to get its component factory and then create an instance of it. That is just my impression. Take my word with a grain of salt

[pixelbits-mk]

All you need to do is create a separate widgets module that declares all your dynamic components and also includes them as entryComponents. Then import this module from AppModule. This will ensure that your entry components are registered with the root injector.

This solution is clean and doesn't break Lazy encapsulation.

@NgModule({
  declarations: [
    ModalComponent,
    ... more dynamic components ...
  ],
  entryComponents: [
     ModalComponent,
    ... more dynamic components ...
  ]
})
export class DynamicModule {

}

AppModule:

@NgModule({
   declarations: [
      AppComponent
   ],
   imports: [
      BrowserModule,
      AppRoutingModule,
      BrowserAnimationsModule,
      DynamicModule
   ],
   providers: [],
   bootstrap: [
      AppComponent
   ]
})
export class AppModule { }

[lucasbasquerotto]

@pixelbits-mk That would make all the dynamic components (like modal and the like) eager loaded, but the point here is make them being able to be lazy loaded to not slow down the initial load of the app (especially as the project grows), just like the components that call them.

Let's say that a lazy loaded ComponentA calls dynamically a lazy loaded dynamic ComponentB. If ComponentA knows that it will call ComponentB you can just import ComponentBModule in ComponentAModule. This is not the ideal case, but I can live with it.

The main problem arises (in my opinion) when ComponentA doesn't know that ComponentB will be loaded. For example, if ComponentB is a modal and ComponentA calls a method showModal() in a service, and the service loads ComponentB dynamically behind the scenes, ComponentA wouldn't know that.

What I do now is including the ComponentB reference as a parameter in the method, like showModal(ComponentB), in such a way that ComponentA now knows that the ComponentB will be loaded, but that's bad in my opinion (each call to the method must pass the component reference).

If Entry Components were available without having to import their modules explicitly (what I think this issue is about), that would solve it (maybe Angular could have a way to detect that ComponentA calls a service that imports ComponentB and make ComponentAModule import implicitly ComponentBModule, and although it could have the undesirable effect of also importing modules of components whose references are imported but the reason of the import is not to create them dynamically, I would see this more as an edge case, and would be okay with it).

I haven't tested (yet) @jonrimmer suggestion, but that seems promising.

[MaklaCof]

It would be awesome if ComponentA would automatically lazy load module with ComponentB only if ComponentA is displayed:
ModuleA has component ComponentA1, ComponentA2.
ComponentA1 reference in html ComponentB (in module ModuleB), but ComponentA2 doesn't.
ModuleB would be automatically lazy load only if ComponentA1 is displayed, but not if ComponentA2 is displayed.

This would perfectly fit scenario of dashboards on home page. Dahsboards comes from many different modules, but if dashboard is not included (let's say through user settings), there is no need to download that module.

[riede]

@jonrimmer Great idea to wrap the resolveComponentFactory function of the main ComponentFactoryResolver and search the registered lazy load modules before.

It works with entry components which inject services that are provided in root. But I can not inject a service that is only provided in the lazy load module. In this case I got a StaticInjectorError. Can you please check it?

[tommyc38]

I wanted to confirm that ivy seems to take care of this issue. I just stumbled on this issue today when I rewrote my modules to be lazy loaded which contained entry components and a shared services to instantiate them only to find a new error stating the component factory couldn't be found. I was actually shocked to read this was an issue in the first place.

At any rate, I just enabled ivy in my existing angular 8.2 project and all seems to be working as expected.

[mixrich]

My solution for usage the Overlay in lazy loaded modules:
You have to pass factory resolver to ComponentPortal's contructor like this

@Injectable()
export class OverlayService {

  constructor(
    private overlay: Overlay,
    private componentFactoryResolver: ComponentFactoryResolver
  ) {
  }

  open<T>(component: ComponentType<T>) {
    const overlayRef = this.overlay.create();

    const filePreviewPortal = new ComponentPortal(component, null, null, this.componentFactoryResolver);

    overlayRef.attach(filePreviewPortal);
  }
}

but you also have to proide OverlayService in lazy loaded module. It's need for OverlayService to inject ComponentFactoryResolver of module in which OverlayService is Provided

@NgModule({
  declarations: [
     SomeComponent,
  ],
  entryComponents: [
    SomeComponent,  // <-------- will be opened via this.overlayService.open(SomeComponent)
  ],
  providers: [
    OverlayService, // <--------
  ]
})
export class LazyLoadedModule {}

[rsrgithub]

@mixrich This approach will work [in my app, I am doing like that and it works fine until I need to close all the modal dialogs on some event like logout] but keep in mind that this will instantiate the OverlayService every time when other module imports this module i.e. the app will not have a single instance like services used to be.

Because there will be no signalton of overlay service it will NOT be easy to know how many modal dialogs are opened.

Of course, it is app's requirements but just to be cautious of this approach.

[mixrich]

@mixrich This approach will work [in my app, I am doing like that and it works fine until I need to close all the modal dialogs on some event like logout] but keep in mind that this will instantiate the OverlayService every time when other module imports this module i.e. the app will not have a single instance like services used to be.

Because there will be no signalton of overlay service it will NOT be easy to know how many modal dialogs are opened.

Of course, it is app's requirements but just to be cautious of this approach.

For example, in my case I have ModalDialogModule with provided OverlayService and when I call OverlayService.open(SomeComponent) it also create for me the modal window tempate, inserts SomeComponent inside it and returns back some data structure with helpful observables (for close and success events), component instance and manual close method.
So, when I need to use modals in my LazyModule I just need to import the ModalDialogModule to it for getting the ability to use OverlayService. I found this approach convenient, bacause you always know that to use modal you have to import the ModalDialogModule, like you always know that to use reactive forms you have to import ReactiveFormModule

[asmith2306]

I got this working in Angular 8.3.6. I have a library module with entry components (mat dialogs) that won't load if I add them to the library modules entry components. It says can't find component factory for MyCustomDialog in the console log when I tried to open it.

Solution is to create a static method in the library module's NgModule class that returns an array of all the module's entry components. Then call this method from the app modules NgModule.

@NgModule({
    declarations: [
        MyCustomDialogComponent
    ],
    imports: [
        CommonModule
    ],
    exports: [
        MyCustomDialogComponent
    ]
	// no need to add the dialog component to entryComponents here.
})
export class MyCustomModule {
    static getEntryComponents() {
        const entryComponents = [];
        entryComponents.push(MyCustomDialogComponent);
        return entryComponents;
    }
}

import {MyCustomModule} from 'my-custom-library'; // import library from node_modules

@NgModule({
    declarations: [
        AppComponent
    ],
    imports: [
        BrowserModule,
        AppRoutingModule,
        BrowserAnimationsModule,
        MyCustomModule
    ],
    providers: [],
    bootstrap: [AppComponent],
    entryComponents: [].concat(MyCustomModule.getEntryComponents())
})
export class AppModule {
}

I know this still doesn't fix the entryComponents in the library not working but at least with the static method the app module doesn't have to know about the entry components in the custom library. It just calls that method and gets whatever is listed in the library. There's no responsibility on the app to know what components in the library are entry components.

[denkerny]

@asmith2306 why do you not use spread operator? it looks ugly

[asmith2306]

@asmith2306 why do you not use spread operator? it looks ugly

Because it doesn't work with it. There's a bug about it somewhere.

[denkerny]

looks like it doesnt work with --prod mode

[broweratcognitecdotcom]

Even if it did work, it does not address the REAL problem. the problem is if I add a component to the entryComponents of an NgModule, and that module is imported into a lazily loaded module in my app, then the entryComponents should automatically get registered with the apps entry components. There should be no further work required. I would further say that any component in the entryComponents of any NgModule should automatically wind up in the entryComponents of the app module. This is currently not the case. If it were then we wouldn't be here.

[mlc-mlapis]

@broweratcognitecdotcom What about conflicts and priorities from different injection levels?

[Dzhuneyt]

@mlc-mlapis order should be on a first-come, first-served basis in my opinion.

[broweratcognitecdotcom]

@mlc-mlapis Do you mean if different components have the same name? First match or an error if there are multiple matches. I could live with a requirement that entry component names must be unique.

[mlc-mlapis]

@broweratcognitecdotcom Hi, yes. Because all variants have to be covered if we are talking about general principles.

[broweratcognitecdotcom]

@mlc-mlapis I think that the limitation in angular that many would like to overcome is that entry components can only be instantiated and placed in the dom by the app. The app does not need to know about a dialog box that a module that I import into a lazy loaded module uses. The current concept of entry components breaks the modular pattern of angular.

[Airblader]

AFAIK with Ivy entryComponents will no longer be necessary, right? Since components will have locality so just dynamically importing them will always work?

[mlc-mlapis]

@Airblader You are right, we know. It was just a small reminiscence back to history. 😄

[th0r]

For those who still struggling with this issues here is the solution that actually works: #14324 (comment)

[Jimmysh]

I publish a package for this issues. some code copy from jonrimmer.
It looks like that the issue does not exist in Angular 9. If you need fix this now. you can use @aiao/lazy-component
sample code here
https://github.com/aiao-io/aiao/tree/master/integration/lazy-component

[pkozlowski-opensource]

I believe that this is fixed in Angular v9 running ivy. If anyone still faces similar problems, please open a new issue with a minimal reproduce scenario. Thnx!

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}