Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Route-specific app-shell: prerendering dynamic parameterized pages

Offen
#29,425 4 Kommentare 42 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
angular, typescript
Bereich
build-system

Rechercherichtung

Beginne mit der Dokumentation zum hybriden Rendering von Angular für parametrisierte Routen und sieh dir anschließend die in app.routes.server.ts gezeigte Konfiguration der Prerender-Routen sowie das Beispiel für Server-Middleware in server.ts an. Vergleiche das angeforderte Verhalten für posts/** mit dem bestehenden Ansatz getPrerenderParams; als erledigt gilt die Aufgabe, wenn ein routenspezifisches, vorab gerendertes Grundgerüst beliebige dynamische Parameter ohne benutzerdefinierte Middleware bedienen kann.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
27k
Forks
11.8k
Ø Merge
17 Std. 25 Min.
Gemergte PRs (30 T.)
183

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus angular/angular-cli

Alle Issues in angular/angular-cli

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.