What about a path like '/product/:first/**/:second'? Not sure if we allow segments after ** (reading this PR, seems like no?), but presumably we at least allow them before? Is this feature limited to either /:first xor /**?

I feel like we could support both with something like:

{
  path: '/product/:first/**/:second',
  renderMode: RenderMode.Prerender,
  async getPrerenderParams() {
    return [
      {'first': 'foo', __spread__: ['category', '1'], 'second': 'bar'},
      {'first': 'bar', __spread__: ['category', '2'], 'second': 'foo'},
    ];
  }
}

Not sure exactly the right way of identifying the spread array though. Maybe a Symbol imported from @angular/ssr?

Is there a better way of mixing ** and :foo syntax in the same path? Is :foo/** a rare enough pattern that we just don't care at this stage?

/product/:first/**/:second is not a valid Angular router route. Also, we did not allow this before.

Edit
Thinking a bit more, /product/:first/** would be a valid route, but in that case, the route can also be defined as as /product/**.

Thinking a bit more, /product/:first/** would be a valid route, but in that case, the route can also be defined as as /product/**.

What about /product/:first/owner/**? I don't think we can generally assume you can always collapse the :params into **?

Thinking a bit more, /product/:first/** would be a valid route, but in that case, the route can also be defined as as /product/**.

What about /product/:first/owner/**? I don't think we can generally assume you can always collapse the :params into **?

Yes, this is not handled at the moment, maybe the simplest would be to allow something like instead of changing the signature of the function

{
  path: '/product/:first/**',
  renderMode: RenderMode.Prerender,
  async getPrerenderParams() {
    return [
      {'first': 'foo', '**': 'category/1', 'second': 'bar'},
    ];
  }
}

Would it be worth getting some wider feedback from the team (Andrew or Jan in particular)? Maybe a quick one-pager would be enough to get some quick thoughts on the approach.

I'm open to {'**': 'foo/bar'}, but also can see that being a little awkward. Presumably /foo/:**/bar is not allowed as a path so there's no ambiguity (if not, it probably should be banned)?

I like ** as a key because it's easy to remember. More generally, I'm in favor of an API that is consistently either a Record or an array, especially because of the mix case. Replacing /prod/:id/** with /prod/** removes the route param as a readable property on the activated route (or from component inputs if enabled), so it's not just an "free" change.

Afaict there's no pre-existing name for the value captured from the wildcard.

@atscott, any thoughts?

@AndrewKushnir might also have some quick thoughts here.

@AndrewKushnir might also have some quick thoughts here.

Thinking a bit more, /product/:first/** would be a valid route, but in that case, the route can also be defined as as /product/**.

I'm wondering what are the use-cases for this feature? What would be "hiding" behind the ** symbol: would we only have static paths or dynamic segments (like :first). My thinking is that allowing dynamic segments might be confusing, since in the getPrerenderParams() function we'd need to return a set of values for keys that are not present in the URL, so as a developer I'd need to reconcile this with corresponding routes in the main routing file (also it'd be a challenge to keep things in sync).

Potentially, we can apply the following rules:

• ** can only be present at the end of the URL pattern
• ** can only be capturing static segments (i.e. a pattern like products/** is not valid for products/:id), so there is always a direct mapping between dynamic segments and corresponding values returned from the getPrerenderParams() function

However, I'm not sure if that would be too limiting for the use-cases that this feature is improving.

I'm wondering what are the use-cases for this feature?

One example is when catch-all routes need to be prerendered. For instance, see this issue: #30035. In such cases, parameterized routes can't be used effectively because the nesting depth is arbitrary.

As for the rules you mentioned, those sound good to me, and I don't see them as restrictive.

@dgp1130 PTAL

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