Route-specific app-shell: prerendering dynamic parameterized pages

[vzarskus]

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

platform-server

Description

We have a use case, where we would like to always show the same prerendered page skeleton/carcass on a route that has dynamic parameters.
Looking at the new Angular server documentation, I do not see such option https://angular.dev/guide/hybrid-rendering#parameterized-routes.

Basically we would like posts/:id to return a single prerendered page for any :id parameter.

This page would show a loading skeleton and would let the browser handle the exact :id and the logic related to it.

Proposed solution

Add a wildcard ** route option that would indicate to Angular that this prerendered page handles any dynamic route parameters.

These wildcards could be used as the dynamic parameter in the build time when prerendering happens. It would be the component's responsibility to correctly handle the ** parameter and show some parameter-agnostic content (loaders/skeletons) that would then be prerendered by Angular and served by the server accordingly.

How it could look in app.routes.server.ts:

{
    path: 'posts/**',
    renderMode: RenderMode.Prerender
},

Excerpt from the imaginary post.component.ts:

private subscribeRouter() { // called in ngOnInit
    this.activatedRoute.params
      .pipe(takeUntilDestroyed(this.destroyRef))
      .subscribe(params => {
        const id: string = params.id;

        if (id === '**') {
          this.isCarcass = true; // post.component.html will render some skeleton/loader if isCarcass === true
        } else {
          this.getPost(id);
        }
      });
  }

Alternatives considered

I am currently considering:

1. Adding a "fake" route parameter that I would configure Angular to prerender.
2. This route would render the skeleton/carcass of the page as per my use case.
3. Serving the route myself in server.ts with a middleware that runs before any middleware generated by Angular CLI.

app.routes.server.ts:

{
    path: 'posts/:id',
    renderMode: RenderMode.Prerender,
    getPrerenderParams(): Promise<Record<string, string>[]> {
      return Promise.resolve(['carcass'].map(i => ({ id: i })));
    }, // prerenders in browser/posts/carcass
 },

server.ts:

// My new middleware
app.use(
  '/posts/:id',
  express.static(join(browserDistFolder, 'posts', 'carcass', 'index.html'), {
    maxAge: '1y',
    redirect: false,
  }),
);

// Default generated by Angular
app.use(
  express.static(browserDistFolder, {
    maxAge: '1y',
    index: false,
    redirect: false,
  }),
);

// Default generated by Angular
app.get('/**', (req, res, next) => {
  angularApp
    .handle(req)
    .then(response =>
      response ? writeResponseToNodeResponse(response, res) : next(),
    )
    .catch(next);
});

I have tested this approach and it works fine, however, it feels pretty hacky.

[alan-agius4]

It sounds like you're looking to implement an app shell with more granular control, where specific app shells can be assigned to individual routes instead of relying on a single app shell for the entire application.

At the moment, this level of control is not something we support out of the box.

[angular-robot]

This feature request is now candidate for our backlog! In the next phase, the community has 60 days to upvote. If the request receives more than 20 upvotes, we'll move it to our consideration list.

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

[martyganz]

@vzarskus we have a similar problem/approach. I've made a small reproduction on how we render separate components on the server vs. on the client. It might be able to help you out. The trick is to provide different routes for server routing than on client in combination with hybrid rendering.

Repo is here: https://github.com/martyganz/hybrid-demo

[vzarskus]

@martyganz the problem is with parameterized routes.
Let's say instead of /trip, you had /trip/:id. You want to use one Prerendered "shell" for any id. There is no way via Angular configuration to achieve that. Well, at least we could not figure out one.