Route-specific app-shell: prerendering dynamic parameterized pages
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
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:
- Adding a "fake" route parameter that I would configure Angular to prerender.
- This route would render the skeleton/carcass of the page as per my use case.
- Serving the route myself in
server.tswith 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
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus angular/angular-cli
-
area: @angular/build gemini-triaged
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
angular/angular-cli#33955 ·
-
area: @angular/cli gemini-triaged
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
angular/angular-cli#33055 · 1 Kommentar · 3 Reaktionen ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34131 · 1 zugewiesene Person ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34130 · 1 zugewiesene Person ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34128 · 1 zugewiesene Person ·
Alle Issues in angular/angular-cli
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
bug v2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
modelcontextprotocol/inspector#2458 · 1 Kommentar ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 75/100
railmapgen/rmp-gallery#4068 ·
-
Mend: dependency security vulnerability status: needs triage 🕵️♀️
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
carbon-design-system/ibm-products#9907 ·