I signed it!

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

Well @jasonaden
It seems that this has some lifecycle implications, and this cannot be handled with <router-outlet [attr.name]="activatedRoute.outlet">, so my current workaround is a custom NamedOutletComponent with this template:

<ng-container [ngSwitch]="route.outlet">
  <router-outlet *ngSwitchCase="'order'" name="order"></router-outlet>
  <router-outlet *ngSwitchCase="'customer'" name="customer"></router-outlet>
  <router-outlet *ngSwitchCase="'tickets'" name="tickets"></router-outlet>
</ng-container>

dirty but works for my lazy-loaded outlets:

{
  path: 'display,
  component: DisplayContainerComponent,
  children: [
    {
      path: ':id',
      component: NamedOutletComponent,
      loadChildren: './tickets/tickets.list.module#AdminTicketsListModule',
      outlet: 'order'
    },
    {
      path: ':id',
      component: NamedOutletComponent,
      loadChildren: './tickets/tickets.list.module#AdminTicketsListModule',
      outlet: 'customer'
    }
  ]
}

This case is not covered by the current EmptyOutletComponent nor the integration tests.

Hi @atscott, glad you're looking to this PR!
I've setup a reproduction case at https://stackblitz.com/edit/angular-pull-30444
with the kind of setup that highlighted this stuff, using outlets to implement some "entity widgets".

I see that you are working on #38379, can you help me to setup some tests please?
I need help with them because currently I haven't the time nor the experience with this kind of stuff :(
I have never built the angular packages locally to be able to check that the final result is the expected one.

@atscott thanks for the info, I've tried to workaround the RouterOutlet.name @Input with no joy
the idea was to let EmptyOutletComponent to pass the respective outlet name as I did with the ngSwitch workaround.

Looking at the implications of this, now I understand that ActivateRoutes.activateRoutes needs the outlets to be set in the constructor, because the RouterOutlet.ngOnInit runs after the router already reported A router outlet has not been instantiated during routes activation.

The router is a whole universe, maybe we could ask @vsavkin for hints
to understand if this case scenario is too crazy for the original concept.

@atscott thanks for the info, I've tried to workaround the RouterOutlet.name @Input with no joy
the idea was to let EmptyOutletComponent to pass the respective outlet name as I did with the ngSwitch workaround.

Looking at the implications of this, now I understand that ActivateRoutes.activateRoutes needs the outlets to be set in the constructor, because the RouterOutlet.ngOnInit runs after the router already reported A router outlet has not been instantiated during routes activation.

That would explain why @Attribute was used instead of @Input. Why do you need to change it to @Input though? Is there a reason this wouldn't work using @Attribute still?

The router is a whole universe, maybe we could ask @vsavkin for hints
to understand if this case scenario is too crazy for the original concept.

Victor isn't on the team any longer and neither is Jason so we have to learn the universe ourselves. The change you have for EmptyOutletComponent seems correct as I described above and it's reasonable to want routes other than just the empty path match there. It may not make sense to have primary routes under a named outlet which is what the component is doing right now.

Edit: That may just be how it works though. Child routes under a named outlet seem to be written as primary routes, without the outlet name of their parent. Maybe that makes sense too so you're not writing named outlets within named outlets and you don't have to remember the parent outlet name. The routes of the children could then be used inside of a named outlet or on their own. If that's the case then I suppose the named outlets aren't intended to be used the way your example is trying to use them.

@atscott thanks for this pair-programming async session hehe
I've added a lazy attribute to router-outlet so it doesn't try to initialize itself in the constructor, but in the ngOnInit, which is also supported by ActivateRoutes.activateRoutes :)

I've also included your considerations around standardizeConfig so we inherit the outlet along the tree of children or lazy-loaded modules (loadChildren) but your consideration is right about the original design. Primary routes are supported inside secondary outlets because all Angular Apps uses a plain <router-outlet> and the name is not mandatory, it defaults to primary as "wildcard" but not strictly speaking to a "primary" tree.

I will think about it again. Thanks for the feedback tho!

I've added a lazy attribute to router-outlet so it doesn't try to initialize itself in the constructor, but in the ngOnInit, which is also supported by ActivateRoutes.activateRoutes :)

It's still not clear why you need to change it to an @Input in the first place. Why is this necessary (because you @Attribute has to be a static value)? It would be good to a comment in the RouterOutlet about why @Attribute doesn't work and why lazy is needed with @Input.

I've also included your considerations around standardizeConfig so we inherit the outlet along the tree of children or lazy-loaded modules (loadChildren) but your consideration is right about the original design.

Let's refactor this to be standardizeConfig(route: Route, parent: Route|null). The function is only used internally in a few places and it would be better to be explicit about how it's being used rather than having optional parameters.

Primary routes are supported inside secondary outlets

Yes, but the question really is: why doesn't this work for you? Unless you need the outlet name to be correct (which you can still do by looking at the pathFromRoot in the ActivatedRoute and read the outlet names in each to determine it), your example could be rewritten to just use a single Route for the primary outlet: https://stackblitz.com/edit/angular-pull-30444-mjqzs3?file=src%2Fapp%2Fentity%2Fentity.module.ts. If the problem is that you actually need different configurations based on the outlet, then you should create different routes rather than trying to share one.

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