fix(@angular/ssr): handle nested redirects not explicitly defined in router config #28906

alan-agius4 · 2024-11-20T12:14:47Z

This commit ensures proper handling of nested redirects that are implicitly structured but not explicitly defined in the router configuration.

Closes #28903

dgp1130

Question: Is the intent here to make it so redirectTo: '/foo' is relative to the base URL while redirectTo: 'foo' or redirectTo: './foo' is relative to the current route?

I do wonder if redirectTo: 'foo' might be confusing and ambiguous for some devs, but it seems like this aligns with the app router at least?

packages/angular/ssr/src/app.ts

packages/angular/ssr/src/routes/ng-routes.ts

alan-agius4 · 2024-11-21T09:50:27Z

Question: Is the intent here to make it so redirectTo: '/foo' is relative to the base URL while redirectTo: 'foo' or redirectTo: './foo' is relative to the current route?
I do wonder if redirectTo: 'foo' might be confusing and ambiguous for some devs, but it seems like this aligns with the app router at least?

The Angular router offers various ways to define redirects, and the goal here is to support these options. I agree that it can be confusing and ambiguous—personally, I also found it difficult to fully grasp how redirects work. The fact that an empty string is interpreted as a trailing slash.

Example of Route Configuration:

const routes: Routes = [
  {
    path: '',
    pathMatch: 'full',
    redirectTo: 'some',  // Redirects to '/some'
  },
  {
    path: ':param',
    children: [
      {
        path: '', // This is treated as a /
        pathMatch: 'full',
        redirectTo: 'thing',  // Redirects to './thing' (relative to :param/) IE: :param/thing
      },
      {
        path: 'else',  // This is treated as /else
        pathMatch: 'full',
        redirectTo: 'thing',  // Redirects to './thing' (relative to :param/else) IE: :param/else/thing
      },
      {
        path: 'thing',
        component: DummyComponent,
      },
    ],
  },
];

I updated the logic to actually resolve these during extraction.

change logic

…router config This commit ensures proper handling of nested redirects that are implicitly structured but not explicitly defined in the router configuration. Closes angular#28903

dgp1130

Oof, that router logic seems quite confusing. I recommend writing down some of these rough edges in a doc somewhere and we can potentially have a conversation with Andrew Scott when he gets back about finding opportunities for simplifying some of this stuff.

So far I've generally insisted to align with app router to maintain consistency, reduce scope by not changing the app router, and remove barriers to adoption. But longer term, it would be great to smooth over some of these rough edges in both routers now that we have more ownership over the SSR side of the problem.

packages/angular/ssr/src/utils/url.ts

dgp1130 · 2024-11-21T19:50:17Z

packages/angular/ssr/src/utils/url.ts

+    return new URL(urlTemplate, baseUrl);
+  }
+
+  if (urlTemplate[0] !== '/') {


Consider: Should this check go first? Otherwise constructUrlWithPlaceholders('foo', new URL('http://example.com/bar')) would be valid?

packages/angular/ssr/src/utils/url.ts

dgp1130 · 2024-11-21T19:57:35Z

packages/angular/ssr/src/utils/url.ts

+ * console.log(staticUrl.toString()); // Outputs: 'http://example.com/static/path'
+ * ```
+ */
+export function constructUrlWithPlaceholders(urlTemplate: string, baseUrl: URL): URL {


Consider: I got confused way longer than I should have thinking that baseUrl was a representation of baseHref. Maybe the naming could be more clear about the intent here.

Is this function only used for redirects? Maybe we should embed that into the naming like:

function buildRedirectUrl(toPath: string, fromUrl: URL): URL;

WDYT?

dgp1130 · 2024-11-21T20:04:17Z

packages/angular/ssr/src/utils/url.ts

+ * @example
+ * ```typescript
+ * const resolvedUrl = constructUrlWithPlaceholders('/:id/details', new URL('http://example.com/user/123'));
+ * console.log(resolvedUrl.toString()); // Outputs: 'http://example.com/123/details'


Question: I'm not following this example, what kind of router config is this coming from? How do we map :id to 123? The implementation makes it seem like we're zipping the two segment arrays and lining up segments at the same location, but that would match :id with user, not 123. Is there an error in this example or am I just misunderstanding something?

The example is wrong, I’ll update it

dgp1130 · 2024-11-21T20:09:44Z

packages/angular/ssr/src/utils/url.ts

+ * console.log(staticUrl.toString()); // Outputs: 'http://example.com/static/path'
+ * ```
+ */
+export function constructUrlWithPlaceholders(urlTemplate: string, baseUrl: URL): URL {


Consider: I suspect this function is coupling two different problems together which might be unrelated:

Resolve a path from a particular URL.

Carry over URL parameters.

I wonder if there's an alternative design which might be able to decouple them. What if we:

Calculated redirects statically by looking at the route list and generating absolute templates.
const serverRoutes = [ { path: ':id', children: [ { path: 'foo' }, { path: 'bar', redirectTo: 'foo' }, // Assuming this redirects to `/:id/foo`, which I might be wrong about. ], }, ];
We could take this and generate a static list of absolute routes (['/:id/foo', '/:id/bar']), I imagine we already have something close to this if not this exact thing in the RouteTree.

Still statically, identify redirects between paths ({['/:id/bar']: '/:id/foo'}).

Whether this is done at build time or server initialization is up to you, point is we haven't see any real URLs yet.

Then at runtime, we would receive /1234/bar, match that as /:id/bar and extract { id: '1234' }.

Resolve the redirect to /:id/foo.

Apply the same params to get /1234/foo.

I think we already do 1. - 3. this way, but just spelling them out for clarity. My main point is separating 4. and 5. into distinct steps and allow us to decouple path resolution from applying parameters. WDYT?

4 and 5 are already done separately in constructUrlWithPlaceholders

I think my point is that we've put 4. and 5. under a distinct abstraction (constructUrlWithPlaceholders), coupling them together. I was thinking it might make more sense to inline these two steps in src/app.ts, but renaming that function to something more meaningful might be fine (buildRedirectUrl, resolveRedirect, etc.) since that would better define this abstraction.

The other piece is that we are copying URL parameters from one string to another (again, coupling the idea of applying parameters to resolving redirects). I'm thinking that it might be clearer to implement step 5. specifically as applying parameters from an independent object. Whether that's literally:

const params = extractParams(baseUrl); const redirectUrl = applyParams(redirectUrlTemplate, params);

in constructUrlWithPlaceholders or if we can reuse parameters extracted previously and just apply them to the redirect URL.

This probably isn't super important, my intuition is that the intent would be easier to follow if we apply a given set of parameters to a URL template instead of trying to copy over specific segments from one URL to another. Just something to consider, it might not actually work out better in practice so I'm fine to defer to you in the end.

dgp1130 · 2024-11-21T20:31:05Z

packages/angular/ssr/src/routes/ng-routes.ts

@@ -546,6 +563,14 @@ export async function extractRoutesAndCreateRouteTree(
      metadata.redirectTo = joinUrlParts(baseHref, metadata.redirectTo);
    }

+    // Remove undefined fields


Question: What exactly is the goal with deleting these fields? Do we not want to leak them to users? A more descriptive comment might be helpful here.

To avoid having to update a bunch of unit tests whenever we add a new field or make some changes.

I encountered this also in the preload PR.

dgp1130 · 2024-11-21T21:18:56Z

packages/angular/ssr/src/routes/router.ts

@@ -7,7 +7,7 @@
 */

 import { AngularAppManifest } from '../manifest';
-import { stripIndexHtmlFromURL } from '../utils/url';
+import { joinUrlParts, stripIndexHtmlFromURL } from '../utils/url';


Nit: Looks unused?

dgp1130 · 2024-11-21T21:29:56Z

packages/angular/ssr/src/utils/url.ts

+ * console.log(staticUrl.toString()); // Outputs: 'http://example.com/static/path'
+ * ```
+ */
+export function constructUrlWithPlaceholders(urlTemplate: string, baseUrl: URL): URL {


I think my point is that we've put 4. and 5. under a distinct abstraction (constructUrlWithPlaceholders), coupling them together. I was thinking it might make more sense to inline these two steps in src/app.ts, but renaming that function to something more meaningful might be fine (buildRedirectUrl, resolveRedirect, etc.) since that would better define this abstraction.

The other piece is that we are copying URL parameters from one string to another (again, coupling the idea of applying parameters to resolving redirects). I'm thinking that it might be clearer to implement step 5. specifically as applying parameters from an independent object. Whether that's literally:

const params = extractParams(baseUrl); const redirectUrl = applyParams(redirectUrlTemplate, params);

in constructUrlWithPlaceholders or if we can reuse parameters extracted previously and just apply them to the redirect URL.

This probably isn't super important, my intuition is that the intent would be easier to follow if we apply a given set of parameters to a URL template instead of trying to copy over specific segments from one URL to another. Just something to consider, it might not actually work out better in practice so I'm fine to defer to you in the end.

alan-agius4 requested a review from dgp1130 November 20, 2024 12:14

alan-agius4 added action: review The PR is still awaiting reviews from at least one requested reviewer target: patch This PR is targeted for the next patch release labels Nov 20, 2024

angular-robot bot added the area: @angular/ssr label Nov 20, 2024

alan-agius4 force-pushed the redirects-nested branch 4 times, most recently from 698059e to d8e81e6 Compare November 20, 2024 17:12

dgp1130 previously approved these changes Nov 21, 2024

View reviewed changes

packages/angular/ssr/src/app.ts Outdated Show resolved Hide resolved

packages/angular/ssr/src/app.ts Outdated Show resolved Hide resolved

packages/angular/ssr/src/routes/ng-routes.ts Outdated Show resolved Hide resolved

alan-agius4 force-pushed the redirects-nested branch from d8e81e6 to 478f588 Compare November 21, 2024 07:48

alan-agius4 force-pushed the redirects-nested branch from 478f588 to 926873a Compare November 21, 2024 09:50

alan-agius4 requested a review from dgp1130 November 21, 2024 09:51

alan-agius4 force-pushed the redirects-nested branch 4 times, most recently from 113d042 to 9ce8e3d Compare November 21, 2024 12:17

alan-agius4 force-pushed the redirects-nested branch 2 times, most recently from e9f4568 to 7cec59d Compare November 21, 2024 13:17

fix(@angular/ssr): handle nested redirects not explicitly defined in …

3096858

…router config This commit ensures proper handling of nested redirects that are implicitly structured but not explicitly defined in the router configuration. Closes angular#28903

alan-agius4 force-pushed the redirects-nested branch from 7cec59d to 3096858 Compare November 21, 2024 14:04

dgp1130 reviewed Nov 21, 2024

View reviewed changes

dgp1130 approved these changes Nov 21, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(@angular/ssr): handle nested redirects not explicitly defined in router config #28906

fix(@angular/ssr): handle nested redirects not explicitly defined in router config #28906

alan-agius4 commented Nov 20, 2024

dgp1130 left a comment

alan-agius4 commented Nov 21, 2024 •

edited

Loading

dgp1130 left a comment

dgp1130 Nov 21, 2024

dgp1130 Nov 21, 2024

dgp1130 Nov 21, 2024

alan-agius4 Nov 21, 2024

dgp1130 Nov 21, 2024

alan-agius4 Nov 21, 2024

dgp1130 Nov 21, 2024

dgp1130 Nov 21, 2024

alan-agius4 Nov 21, 2024

dgp1130 Nov 21, 2024

dgp1130 Nov 21, 2024

fix(@angular/ssr): handle nested redirects not explicitly defined in router config #28906

Are you sure you want to change the base?

fix(@angular/ssr): handle nested redirects not explicitly defined in router config #28906

Conversation

alan-agius4 commented Nov 20, 2024

dgp1130 left a comment

Choose a reason for hiding this comment

alan-agius4 commented Nov 21, 2024 • edited Loading

Example of Route Configuration:

dgp1130 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alan-agius4 commented Nov 21, 2024 •

edited

Loading