Route-specific app-shell: prerendering dynamic parameterized pages

Ouverte
#29,425 4 commentaires 42 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
angular, typescript
Domaine
build-system

Piste de recherche

Commencez par la documentation d'Angular sur le rendu hybride pour les routes paramétrées, puis examinez la configuration des routes de prérendu présentée dans app.routes.server.ts ainsi que l'exemple de middleware serveur dans server.ts. Comparez le comportement demandé pour posts/** avec l'approche existante de getPrerenderParams ; le travail est considéré comme terminé lorsqu'un squelette prérendu propre à une route peut servir des paramètres dynamiques arbitraires sans middleware personnalisé.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

area: @angular/ssr feature feature: under consideration
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.

Langage dominant
TypeScript
Étoiles
27k
Forks
11.8k
Merge moyen
16 h 35 min
PR mergées (30 j)
176

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de angular/angular-cli

Toutes les issues de angular/angular-cli

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.