You can redirect in the CanActivate guard, can't you ?

Yes, and that's the approach I took. However, I feel that mentally separating redirect and guards is a lot more easy to reason about. Also, using the guard approach, the route still needs a component , children or redirectTo defined.

If there would be no problem, I would be open to implementing it using the same pattern as the CanActivate interface

@vicb canActivate guard for redirects instead of redirectTo does not feel fully supported. The code below will fail with error:

"Invalid configuration of route ''. One of the following must be provided: component, redirectTo, children or loadChildren"

const routes: Routes = [
  { path: '', canActivate: [RedirectGuard] }
];

There is no error when redirectTo and path is used. Adding children: [] works as a workaround, but using "guard" for routing feels a bit weird and clunky sometimes.

I have a bit of advanced use case. The app I'm working on has /:organization/:cluster as parameters. All other routes lie under this route. I would like to have a dynamic redirect from / which uses a UserService to figure out which params to use.

This would also be great for my project as well. In the simplest case, I would be happy to have redirectTo be a function that can take an ActivatedRouteSnapshot and a RouterStateSnapshot as arguments.

I'm using this to support a structure like this:

{
  path: 'topics',
  { topics: TopicsResolver },
  children: [
    {
      path: 'default',
      redirectTo: (route: ActivatedRouteSnapshot, state: RouterStateSnapshot) => {
        return ['topics', route.data.topics[0]];
      }
    },
    {
      path: ':topic_id',
      resolve: { topic: TopicResolver },
      component: TopicComponent
    }
  ]
}

We used a structure like this for our AngularJS app with UI-Router, and it worked very well. I would love to be able to mimic that in Angular.

I know this already is quite old. But I'm in the same situation. I want to redirect from an empty route to another route with dynamic params. Now I have to do this

{path: '', pathMatch: 'full', children: [], canActivate: [RedirectGuard]}

Which is a little ugly and looks like I'm abusing the system.

According to this article, Better Redirects in Angular Route Guards, since Angular 7 it is allowed to return an UrlTree in canActivate.
Still feels weird to do that in something called a "guard" or "can activate", but at least now redirection is properly supported by the framework in guards, and if you read the end of the article, this can neutralize a few potential bug sources.

I know this already is quite old. But I'm in the same situation. I want to redirect from an empty route to another route with dynamic params. Now I have to do this

{path: '', pathMatch: 'full', children: [], canActivate: [RedirectGuard]}

Which is a little ugly and looks like I'm abusing the system.
Hey Is there Any Other Solution To Redirect To that Particular Child Route other than Using canActive.
I am facing the same issue and it will happen only when you trying to load a Module lazily when the App starts. Surprisingly it will work fine if we redirect to this lazy-loaded module from some other module through route.navigate['/LazyModule'].

My Code :

app-routing.module.ts :
const routes: Routes = [
{path: 'tracker', loadChildren: () => import(./feature/tracker/tracker.module).then(m => m.TrackerModule)},
{path: '', redirectTo : '/tracker', pathMatch: 'full'}
];

tracker-routing.module.ts :
const routes: Routes = [
{ path: '', component: TrackerComponent, children :
[
{ path: '',pathMatch : 'full' , redirectTo: 'trackercreate'},
{ path: 'trackercreate', component: TrackerCreateComponent },
{ path: 'trackerlist', component: TrackerListComponent },
{ path: '**', redirectTo: 'trackercreate'}
]
}
];

Expected Behaviour When App Loaded for 1st time (URL) :
http://localhost:4200/tracker/trackercreate

Actual Behaviour Now What I am getting for 1st time App Loading (URL): http://localhost:4200/tracker

Can Anyone Please help me to Understand this Concept, like why this is happening and how to resolve this. Thank You very Much. :)

Maybe making route.paramMap mutable would be enough:
router:

resolve: {
  dynamicIdOrSomethingElse: DynamicResolver 
}
redirectTo: 'dynamic-path/:dynamicId'

DynamicResolver :

resolve(route: ActivatedRouteSnapshot, ...  

  route.paramMap.set('dynamicId', 123)    
  ...

but route.paramMap.set set is not allowed by paramMap.

I have been using the solution like @SamVerschueren wrote for years now. But since angular 14 it's not possible to use pathMatch="full" and a dynamic direct function any more without adding a useless component (read unused/dummy).

@egonknapen just faced with the same issue but it seems that adding children: [], allows you to avoid that dummy component.

@egonknapen just faced with the same issue but it seems that adding children: [], allows you to avoid that dummy component.

Thanks, I tried using children, but I couldn't imagine what to put in it, didn't think about leaving it just empty. So now we got 2 so called hacks [canActivate] + 'children:[]', to get dynamic routing working.

I would suggest angular comes up with their own solution or add the preferred way to their documentation.

Thanks, I tried using children, but I couldn't imagine what to put in it, didn't think about leaving it just empty. So now we got 2 so called hacks [canActivate] + 'children:[]', to get dynamic routing working.

Same here. It seems weird that an empty children array passes validation, but leaving children out does not.
As an alternative to canActivate: [RedirectGuard], I'm using resolve: {resolvedData: RedirectResolver}, and in the resolve function I'm using this.router.navigate().

Reading this thread it seems that canActivate has more of a built in redirect feature, but the resolver works well enough for me

Angular v14 makes this more apparent by validating routes in lazy loaded modules. I think a lot more people are going to run into this missing feature with the common workaround of using a guard.

The empty children array workaround is probably more confusing than the error.

The empty children array workaround is probably more confusing than the error.

I searched in the internet, and found a few articles all describing the same way. So I think it's up to the angular developers, to add their preferred way. It's a valid use case, to want a dynamic routing. If they don't I'm afraid, next time they will come up with another way to prevent us from doing just that.

Of all the components of angular I have been using, the routing had been the most limiting (read less happy with). For example I wish it was more easy to use matrix variables, even when you don't want navigation to happen, for example if you are using tabs, and want the current tab as a matrix variable, so when copy&pasting the url, it will open on the same page.

(But that's outside the scope of this bug-issue)

I have a scenario where different users have a different landing page after sign in. The default landing page is set in the redirectTo but this now needs to become dynamic to accommodate for the different user types.

For example:

• Finance user should be directed to the finance dashboard,
• Driver user should be directed to their jobs page,
• Admin user should be redirected to a business dashboard

Would be helpful if redirectTo can be structured like canActivate and we can access the ActivatedRouteSnapshot.

We have a similar use case when a user goes to /libraries, we want to redirect to one of its children depending on the user's rights. Using the CanActivate guard hack to redirect. Had not thought of using children: [] as I'm updating from ng13->14->15 but it worked, and we were using a resolver which sounds even worse than using a guard.

@epelc I disagree, I used the error message to find this thread as I updated Angular and it was pretty easy.

We have a similar use case when a user goes to /libraries, we want to redirect to one of its children depending on the user's rights. Using the CanActivate guard hack to redirect. Had not thought of using children: [] as I'm updating from ng13->14->15 but it worked, and we were using a resolver which sounds even worse than using a guard.

I personally have the opinion that both are only hacks. I better solution would be something like [RedirectTo] with a function/method behind it. So it would be directly clear, that this function would specify the direct.

But as often I get to hear, it's not in the documentation, it's not planned, end of discussion. But then there are hacks to fix what is missing, until the next time, when they close a way around the problem.

We will see, probably need to make a feature request, and then get at least 20 people to vote for it. But for that we need to wait, we only got 15 people now, watching this.

Just a quick update: I do believe this is a high priority item for the Router. There are some questions that I don't have answers to at the moment but don't have time to fully think about due to other items that are higher priority. Maybe discussions in this issue can explore these and come to a satisfactory answer:

1. Can/should the function return a string that acts like the existing redirects? (probably)
2. Can/should the function also be able to return a UrlTree that is an absolute redirect? (probably)
3. The big one: what parameters does the function get? If we're allowing a UrlTree return value, we're going to want better parameters than what you currently get for canMatch guards (route: Route, segments: UrlSegment[] ) so we can update/retain query params, fragment, and/or path params. How do we get that information? Would it be sufficient to answer this question later and initially release the redirect feature without any parameters? Releasing with parameters that aren't helpful wouldn't be good because (1) the aren't helpful and (2) it might require a breaking change to update them in the future. Would an initially parameter-less function still require a breaking change to add parameters later?