Also, possible fix #10981
@Jonathan002 FYI
@jasonaden May you review?

Any update?

@asvishnyakov Thank you for this, I hope Angular team will take their time to review those few lines of code before v9 is released (although, it might be too much to ask).

Anyways, there are some indentation issues in packages/router/src/apply_redirects.ts which might make things go a bit slower to accept and merge.

This is still not working fully & #10981 (comment) is locked for some reason. Plz halp.

Any updates on this ticket?

• Rebased PR
• reverted .gitignore changes
• Updated routes.map to use try...catch and throwError to ensure possible errors thrown from expandSegmentAgainstRoute are handled by catchError code
• Updated test to more accurately reflect the use-case in the issue report and so that it would fail without the changes in apply_redirects

The internal tests have quite a few failures so this will require further investigation into why this change breaks them.

@googlebot I consent

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

I reviewed one of the failing tests and found that it fails because this finds all configs which match the url tree and loads each one if they have lazy children. The previous behavior would find and load only the first match. Generally, this would be fine because the router usually only activates a single config. Matches that appear earlier in the config take precedence (which is working as intended and documented). The failing provides an override to the real route so that it loads a no-op module. This change makes it so that the test override and the real Route match and are loaded, resulting in the failure.

i.e.

const REAL_ROUTES = [
  {
    path: 'b/c',
    loadChildren: 'xyz',
    pathMatch: 'full'
  },
];
=====

...
{
  testRoutes: [
  routes: [
    {path: 'a/b/c', loadChildren: 'noop_module'},
    {path: 'a', children: REAL_ROUTES},
  ],
}

In our case with these empty path named outlets, we have to load matched configs from each outlet. This approach also presents a problem because it will always load wildcard routes, which will always match the given url tree. At the moment, I can't really think of a solution to this. If no backwards compatible solution can be found, we could provide this as opt-in behavior in ExtraOptions, something like lazyRouteLoadingBehavior: 'firstMatch'|'allMatches'

Edit:
Pushed another fixup commit with a test demonstrating the failure described above

Closing in favor of #38379, as that one addresses the issues mentioned in #32688 (comment)

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