CdkPortalOutlet should resolve componentFactories through the portal's ComponentFactoryResolver

[j2L4e]

Bug, feature request, or proposal:

At the moment, CdkPortal tries to resolve ComponentFactories via its own CFR which it got from its own Injector instance:

const componentFactory = this._componentFactoryResolver.resolveComponentFactory(portal.component);

It may happen that you'd like to attach a ComponentPortal with a lazily loaded entryComponent that's not resolvable through the PortalHost's CFR. It should then try to get a CFR instance from the Portal to resolve the ComponentFactory if it can't resolve it through its own:

const componentFactory = portal.injector.get(ComponentFactoryResolver).resolveComponentFactory(portal.component);

I'm not sure if this has any negative side effects.

[jelbourn]

Are you referring to DomPortalOutletor CdkPortalOutlet?

For the first, it uses whatever ComponentFactoryResolver it is given (it's not injected). When used from the overlay, it will be the resolver associated w/ the overlay service, which is expected since the OverlayModule needs to be imported in any lazy-loaded module that would be using it.

For the second, it will use the ComponentFactoryResolver from wherever in the injection tree the outlet lives. The only way I would see this being a problem is if the ComponentPortal is for a component defined in a sibling module. Is that what you're seeing?

[j2L4e]

I'm talking about CdkPortalOutlet.
And yes, this is about lazily loaded children or siblings.

My specific use case is a navigation menu outlet:
<ng-container menuOutlet="topnav"></ng-container> with MenuOutlet extending CdkPortalOutlet

Modules can bring in their own navigation components through route data. Obviously the outlet lives somewhere higher up in the hierarchy and doesn't know about SomeTopnavComponent's factory when it's part of a lazily loaded module.

  {
    path: 'somePath',
    component: SomeComponent,
    data: {
      topnav: SomeTopnavComponent
    },
  }

It'd be great to be able to pass a ComponentFactoryResolver to CdkPortalOutlet in case one needs to deal with sibling and child modules.

[j2L4e]

@crisbeto you closed the linked PR stating that this wouldn't be necessary in Angular 6+.
Could you elaborate on how resolving factories has changed?

Thank you for your work!

[poke]

@crisbeto I have the same question as @j2L4e.

Basically, as per angular/angular#14324, I am unable to attach component portals to my shared portal outlet when the component I want to render is declared within a lazy loaded module. Since the portal outlet’s component factory resolver does not know about the entry components from lazy loaded modules, I need to use the module’s component factory resolver.

So I need a way to be able to pass the component factory resolver to the component portal, or the portal outlet’s attach method.

The pull request did exactly that, and I can confirm (through monkey patching) that this indeed works for me. But even with Angular 6.1, I do not see how this is possible without being able to pass the factory; or without the outlet retrieving the factory from the injector that is passed through the portal.

Could you clarify why you believe that the changes from that PR are no longer necessary for Angular 6? I might be wrong, but I haven’t been able to find a way around the component factory resolver.

[crisbeto]

@poke If I remember correctly, the "Angular 6+" changes that I mentioned when closing the PR were Ivy, but that hasn't landed yet. @jelbourn do you think we should revisit this?

[jelbourn]

Probably. Have an API in mind?

[crisbeto]

I was thinking of basically doing the same as in #9882 which we closed a while ago, because of Ivy.

[poke]

For what it’s worth, I am using the exact same strategy as in that pull request in a patched version running on 6.1 and that works completely fine. Having to pass an explicit component factory resolver to the attach seems like a fine compromise to make this work.

[jelbourn]

Why make the resolver a parameter to attach instead of an @Input on the directive?

[poke]

The point of this is that you can attach various component portals to the same outlet. So you can attach compontent X of lazy-loaded module A using A’s component factory resolver, and in the next moment you can attach component Y of lazy-loaded module B using B’s component factory resolver. So the component factory resolver you choose is always strongly coupled to the component portal you want to attach.

If this was an input, then you would have to move this logic to the parent component, and you would be pretty much defeating the purpose of component portals and the attach API. Because at that point, you could also just switch to template portals.

The component factory resolver being coupled to the component portal would probably be an argument for moving the component factory resolver reference into the component portal, instead of passing it while attaching.

At that point, this might be an argument for @j2L4e’s original idea, to resolve the component factory resolver from the component portal’s injector. I don’t know if that actually works, but from my experiments, passing the injector to the component portal is not required to make it work. I have been using the outlet’s injector with a component from a different NgModule using that module’s component factory resolver, and that’s been working very well. So if the component factory resolver is moved to the component portal (instead of the attach), it should probably still be an explicit constructor argument or property.

[jelbourn]

That's a good point; you'd want the resolver to be associated with the ComponentPortal in that case. That makes more sense anyway, since TemplatePortal doesn't use the resolver at all. The simplest thing would probably be adding a ComponentFactoryResolver as a 4th argument to the constructor for ComponentPortal. I would shy away from trying to get it from the given injector because someone might want to use an injector from a totally different part of the application tree.

[poke]

I just updated my application to Angular 7 and cdk 7.0.2 and wanted to migrate to this solution. However, I realized that the change that now made it into the release only applies to the DomPortalOutlet. When using the CdkPortalOutlet, which is what this issue was originally about, there is still the same component factory resolver being used.

So unfortunately, the fix for this does not work for me. Any chance we can get this ported to the CdkPortalOutlet as well?

[jelbourn]

Re-opening this for the change still needed in CdkPortalOutlet

[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.}