Router - Routes Config transform hook

🚀 feature request

Relevant Package

This feature request is for @angular/router

Description

Ability to transform/process routes when they are being registered (in order to be filtered/manipulated or so)

Describe the solution you’d like

@NgModule({
    imports: [RouterModule.forChild(ROUTES)],
    providers: [
        { provide: RoutesConfigHandler, useClass: AppRoutesConfigTransformer } // register in root
    ],
    exports: [RouterModule]
})
export class AppShellRoutingModule {

}

class AppRoutesConfigTransformer extends RoutesConfigHandler {

    constructor(
        appInfo: AppInfoService, // custom service
    )

    process(routes: Routes): Routes { // if it can take `Routes | Promise<Routes> | Observable<Routes>` as return even better but probably complicates things
        // perform custom logic on routes - validate data, set some data, filter or so...
        return routes;
    }

}

Describe alternatives you’ve considered

Tried to handle the more angular DI way, however with the router I had no luck. I tried even custom function for RouterModule.forChild (as how it is internally) but still nothing works.

@NgModule({
    imports: [RouterModule.forChild(ROUTES)],
    providers: [
       { provide: ROUTES, useFactory: validateProcessRoutes, deps: [AppInfoService] },
    ],
	exports: [RouterModule]
})
export class AppShellRoutingModule {

}

function validateProcessRoutes(routes: Routes) {
    // perform custom logic on routes - validate data, set some data, filter or so...
    return routes;
}

[stephenlautier]

Oki so one of the examples i mentioned is to iterate through routes and add validation. Again the only problem we have is we are not able to use DI, so the requested feature is to enable DI pretty much, in this case a simple logger.

Validate the Routes has certain data e.g. RouteId in this case

This is how it currently is, and it works (update: doesnt work with AOT) , however in this example we cannot use our own logger (commented below)

export function appProcessRoutes(routes: Routes): Routes {
  return processRoutes(routes, routeIdCheck);
}

function processRoutes(routes: Routes, filterFn?: (route: Route) => boolean | undefined): Routes {
  return _.reduce(routes, (result, route) => {
    const isValid: boolean | undefined = filterFn?.(route);
    if (isValid === false) {
      return result;
    }
    result.push(route);

    if (route.children) {
      route.children = processRoutes(route.children, filterFn);
    }
    return result;
  }, [] as Routes);
}

function routeIdCheck(route: Route): boolean | undefined {
  const data = route.data as AppRouteData;
  if (!data.id) {
    const routeInfo = routeConfigDebugId(route); // code omitted
    // this.logger.error("routeIdCheck", "route has no 'id' specified", {route: routeInfo}); // need to use this
    console.error(`[routeIdCheck] route has no 'id' specified`, routeInfo);
    return false;
  }
}

Now in order to be able to use the logger we would need DI, and this is how we generally create it

constructor(
  loggerFactory: LoggingFactory
) {
  this.logger = loggerFactory.get("AppRoutesConfigTransform");
}

So again, the problem is that we are currently limited to only write code which doesn’t use any services.

Another issue is you need to apply this manually for each individual usage, like this:

@NgModule({
  imports: [RouterModule.forChild(appProcessRoutes(ROUTES))], // <-- like this
  exports: [RouterModule]
})
export class AppShellRoutingModule {

}

While with the other, you register the service once in root and thats it.

// copied from feature request above
@NgModule({
  imports: [RouterModule.forRoot(ROUTES)],
  providers: [
      { provide: RoutesConfigHandler, useClass: AppRoutesConfigTransformer }
  ],
  exports: [RouterModule]
})
export class AppRoutingModule {

}

[Airblader]

Thanks for taking the time to write this up, I appreciate it! I think understanding the use-case helps in finding solutions, be it existing ones or to think about a possible new feature. I’ll follow up with my thoughts on this below, but let’s see what the Angular team thinks about it. 😃

---

Since this is about preventing misconfiguration during development, wouldn’t you rather want this to be a compile-time error rather than a runtime one, though? This could probably be covered in a test that scans the source for routing modules and then performs the checks (although admittedly I don’t know of specific tooling that makes writing such tests straight-forward).

As for a runtime version you could have a service which injects Router and then parses Router#config this way to log the errors. This wouldn’t disable those routes, though this could then still be achieved by keeping that validation result and accessing it from a guard.