use createComponent and ApplicationRef.attachView, the primary router outlet will to be replaced if the dynamically created component contains router-outlet about angular

[JeanMeche]

Hi, is there a reason you're using createComponent + applicationRef.attachView instead of viewContainerRef.createComponent. Because there is no issue in the latter.

[why520crazy]

Hi, is there a reason you're using createComponent + applicationRef.attachView instead of viewContainerRef.createComponent. Because there is no issue in the latter.

Yes

[JeanMeche]

What would be the particular usecase your are looking to address with this?

[atscott]

Closing as expected. This is effectively the same thing as having two router outlets.

[alxhub]

Note that as @atscott mentions, this is effectively replacing the primary router outlet, as it's created as a root-level outlet.

To create it as a child outlet of the root outlet instead, you would need to create the new component as a DI child of the parent RouterOutlet. This is done by passing elementInjector as well as environmentInjector when calling createComponent. See: https://stackblitz.com/edit/ng-create-component-with-outer-outlet-gzentc?file=src%2Fdashboard.ts

[why520crazy]

@alxhub @atscott @JeanMeche thank you very much for providing the solution.

1. Firstly, the current expectation is for version 16.0 to appear, in 15.x it don't replace the primary router outlet, it looks like a breaking change.
2. We are using createComponent + applicationRef.attachView when using a micro front-end for cross application rendering, App1 renders component of another application (App2), App1 can only obtain the applicationRef of App2, If elementInjector can be passed, then simply use viewContainerRef.createComponent instead of the global createComponent.
3. If this is a expected behavior, are there other alternative solutions besides passing elementInjector.

[atscott]

Firstly, the current expectation is for version 16.0 to appear, in 15.x it don't replace the primary router outlet, it looks like a breaking change.

Your example seems to have the same behavior in 15: https://stackblitz.com/edit/angular-3eqbcp

App1 renders component of another application (App2), App1 can only obtain the applicationRef of App2

This seems a bit sketchy. Why is this the case and why aren't the ApplicationRef instances the same? Regardless, I'm not really following why App1 cannot create the App2 component and always pass the elementRef so that the ElementRef hierarchy is preserved for RouterOutlet. This is required to avoid same-name collisions of outlets.

If this is a expected behavior, are there other alternative solutions besides passing elementInjector.

There should be other workarounds. For example, preventing App2 from rendering another outlet with the same name.

[why520crazy]

@atscott

Your example seems to have the same behavior in 15: https://stackblitz.com/edit/angular-3eqbcp

Sorry for my mistake, i only test it use NgModule in 15 : https://stackblitz.com/edit/angular-3tn8ws, I didn't expect that standalone component application would be inconsistent with NgModule app.

This seems a bit sketchy. Why is this the case and why aren't the ApplicationRef instances the same? Regardless, I'm not really following why App1 cannot create the App2 component and always pass the elementRef so that the ElementRef hierarchy is preserved for RouterOutlet. This is required to avoid same-name collisions of outlets.

App1 and App2 are different angular application, they all have independent AppModule and router. I found this issue is due to using the example of @worktile/planet, I open http://planet.ngnice.com/app1/projects after the page, when navigate to App2 again, a blank page appears:

because the /app1/projects page renders a component of App2, and the component template of App2 includes a router-outlet.

There should be other workarounds. For example, preventing App2 from rendering another outlet with the same name.

I think this is a good idea

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