8000 Type RedirectFunction use with Route config property redirecTo asynchornous · Issue #61047 · angular/angular · GitHub
[go: up one dir, main page]

Skip to content

Type RedirectFunction use with Route config property redirecTo asynchornous #61047

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dquirion opened this issue Apr 29, 2025 · 7 comments
Closed

Comments

@dquirion
Copy link

Which @angular/* package(s) are relevant/related to the feature request?

router

Description

Hi, i just came across the new RedirectFunction type used in route config property redirectTo and I was hoping that it supports asynchronous function just as the the canActivateFn/canMatchFn do.

export const redirect = async (route) => {
  const user = inject(UserService);
  // if user is undefined, it asks server if already authenticated
  const isLogged = await user.isLogged()
  return isLogged ? homePage : loginPage;
};

export const routes = [
  // ... 
  {
    path: '**',
    redirectTo: redirect
  }
]

Proposed solution

Support promise or observables just a the guard functions.

type RedirectFunction = (
  redirectData: Pick<
    ActivatedRouteSnapshot,
    'routeConfig' | 'url' | 'params' | 'queryParams' | 'fragment' | 'data' | 'outlet' | 'title'
  >,
) => MaybeAsync<string | UrlTree>

Alternatives considered

Right now i use a canActivateFn guard to achieved the same behavior. But as the doc suggests, I found the RedirectFunction clearer and more logical for such case.

@JeanMeche
Copy link
Member

This should be a canActivate guard. Such redirect is probably the n°1 use case of that guard.

@JeanMeche JeanMeche closed this as not planned Won't fix, can't repro, duplicate, stale Apr 29, 2025
@dquirion
Copy link
Author
dquirion commented Apr 29, 2025

This should be a canActivate guard. Such redirect is probably the n°1 use case of that guard.

Ok great, thanks @JeanMeche for the feedback. I would add that there is one "kind of annoying" thing and this is for a route with only a path and a guard you have to specify either a dummy component or a empty children array. Any plan on making this config without those required fields?

export const routes = [
  // ... 
  {
    path: '**',
    canActivate: [redirectCanActivateFn],
    children: []
  }
]
8000

@JeanMeche
Copy link
Member
JeanMeche commented Apr 30, 2025

Actually the feature will land in v20, see #60863.

@atscott
Copy link
Contributor
atscott commented Apr 30, 2025

Right, this’ll be available in v20 but I’ll also add that I don’t really see where it’s useful. You already need to have your login guard on the home page so why not just have ** unconditionally redirect to the home route?

@dquirion
Copy link
Author
dquirion commented May 1, 2025

Right, this’ll be available in v20 but I’ll also add that I don’t really see where it’s useful. You already need to have your login guard on the home page so why not just have ** unconditionally redirect to the home route?

@atscott with this particulary case you are absolutly right. But my real use case is a bit more complicated since the redirection depends on user's permissions to targets the first allowed page.

Maybe I'm wrong but when a developper have to do something (fix/new feature) and have to touch the routes logic, it's more obvious and clear what will happen if the router fallback on '**'. Instead of navigating to another route config and guard, and undertstand the step the router takes, he or she will have the anwser right in the redirectTo function. What do you think?

@atscott
Copy link
Contributor
atscott commented May 1, 2025

@dquirion Potentially. In the case of the example given here, I don't think duplicating the redirect logic in redirectTo is more understandable. Could you give an example where the redirect would not already be handled by a guard/redirect on the unconditional target route?

@dzhavat
Copy link
Contributor
dzhavat commented May 14, 2025

I need the async redirect in a feature I'm working on right now.

The route setup is roughly the following:

// main.routes.ts
...
{
    path: 'reports',
    loadChildren: () => import('...'),
    canActivate: [LoginGuard],
},
...

// reports.routes.ts
export const routes: Routes = [
  {
    path: '',
    component: Reports,
    canActivate: [PermissionGuard(['permission-a', 'permission-b'])],
    children: [
      {
        path: '',
        pathMatch: 'full',
        redirectTo: 'report-a',
      },
      {
        path: 'report-a',
        canActivate: [PermissionGuard(['permission-a'])],
        loadComponent: () => import('...'),
      },
      {
        path: 'report-b',
        canActivate: [PermissionGuard(['permission-a'])],
        loadComponent: () => import('...'),
      },
    ],
  },
];

Let's say user-a has permission-a. Visiting the /reports route will correctly redirect them to /reports/report-a.
Let's say user-b only has permission-b. Visiting the /reports route will try to redirect them to /reports/report-a but they don't have the permission to see it. Here it'd be nice to redirect them to /reports/report-b instead.

As an important note, the PermissionGuard in our case returns Observable<boolean | UrlTree>. That's why the we need the async redirect feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
0