Route-specific app-shell: prerendering dynamic parameterized pages
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- angular, typescript
- Ambito
- build-system
Direzione di ricerca
Inizia dalla documentazione di Angular sul rendering ibrido per le route parametrizzate, quindi esamina la configurazione delle route di prerendering mostrata in app.routes.server.ts e l'esempio di middleware del server in server.ts. Confronta il comportamento richiesto per posts/** con l'approccio esistente getPrerenderParams; il lavoro è completato quando uno scheletro prerenderizzato specifico della route può servire parametri dinamici arbitrari senza middleware personalizzato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- TypeScript
- Stelle
- 27k
- Fork
- 11.8k
- Merge medio
- 16h 35m
- PR unite (30g)
- 176
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di angular/angular-cli
-
area: @angular/build gemini-triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
angular/angular-cli#33955 ·
-
area: @angular/cli gemini-triaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
angular/angular-cli#33055 · 1 commento · 3 reazioni ·
-
unit-test: with --coverage, a setup file's hooks reach only the first spec file of each worker Apertaarea: @angular/build gemini-triaged
Difficoltà 4/5 3-5 giorni Idoneità per principianti 72/100
angular/angular-cli#34137 ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34131 · 1 assegnatario ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34130 · 1 assegnatario ·
Tutte le issue di angular/angular-cli
Issue simili
-
[Bug]: Discord Activity titles with emoji are rejected as over 80 characters when they are not Apertaclawsweeper:linked-pr-open clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:message-loss issue-rating: 🦞 diamond lobster maturity:stable P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
Eynzof/Hermes-CN-Desktop#616 ·
-
ZCode 3.14.3 に対応する Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
supermomonga/zcode-acp#24 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
growthbook/growthbook#7100 ·
-
triage
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100