Enable declaration of async routes for static prerendering

[michaeljota]

Proposal

What is the summary of the proposal?

Enable declaration of async routes for static prerendering to be able to calculate dynamic URLs.

What is the proposal?

Right now, Angular Universal has two ways to declare the routes for static prerendering, but both are sync solutions. One is declaring the routes as an array inside the "routes" option of @nguniversal/builders:prerender builder, and the other one is declaring the routes as newline-separated values inside a .txt file and declare it in "routesFile" option of the same builder.

My proposal is to add another option to the @nguniversal/builders:prerender, like "asyncRoutes", that accepts a TypeScript file, exporting a named async function that accepts enough params to be able to make requests on its own and returns a string array with the routes.

This proposal would allow getting the params of dynamic routes, for example, a complete list of posts according to their ID, or friendly URL. Things that would require a lot of work each time a new one is added.

One of the requirements of this would be, be able to make requests and process the responses without external libraries. For this I'm thinking about two different solutions:

a) The function can be called with arguments that allow this behavior. Ideally, an instance of HttpClient would be injected, but as far I can tell, HttpClient uses XMLHttpRequest object, that's only available in the Browser, the HttpClient would be available only inside an Angular application, and other considerations that I think make this unviable.

However, we would only need to call the function with an object with the same shape as HttpClient. The idea behind this is for the programmers to work with a known interface to calculate the routes of their application.

b) A complete Angular Service implementing an interface with the method to be called. I think this would be more complex to do but would allow reusing the same services that are probably being used to gets the details of the routes.

Is there anything else we should know?

• NextJS Implementation: getStaticPaths

[wagnermaciel]

@alan-agius4 I think this would actually be a good idea. It would also help alleviate some of the problems we were seeing in this issue: https://github.com/angular/universal/issues/1769

[MarcoGlauser]

From a user perspective, the current way of passing routes is one of the pain points when using prerendering.

We wrote quite some code to dynamically generate the routes for content living in a cms.(Also building on angular/universal#1736) This code feels quite fragile, as it's dependent on both angular routes not changing, and evolving content from the CMS. Additionally, it duplicates code which is already present in the Angular application.

I don't know how Universal works under the hood but in my opinion, the best place to define the routes for prerendering would be within the angular application. It creates all the rules for routing in the first place and anything external ends up trying to replicate the same. So I would love to see option b) at some point in the future and be able to alleviate some of our technical debt :)

[angular-robot[bot]]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[michaeljota]

@alexcibotari I saw you opened another issue related to this one, and with this one requesting upvotes, maybe you want to upvote. Still, I don't think this will get the upvotes it deserves.

Is there something else we could do here @alan-agius4?

[angular-robot[bot]]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.