Route-specific app-shell: prerendering dynamic parameterized pages
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
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.
- 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
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de angular/angular-cli
-
Can't use an array of hostnames in --allowedHosts cli parameter in @angular/build:dev-server Ouvertearea: @angular/build gemini-triaged
Difficulté 2/5 1-3 heures Accessibilité débutants 74/100
angular/angular-cli#33955 ·
-
area: @angular/cli gemini-triaged
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
angular/angular-cli#33055 · 1 commentaire · 3 réactions ·
-
unit-test: with --coverage, a setup file's hooks reach only the first spec file of each worker Ouvertearea: @angular/build gemini-triaged
Difficulté 4/5 3-5 jours Accessibilité débutants 72/100
angular/angular-cli#34137 ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34131 · 1 personne assignée ·
-
angular/build:library area: @angular/build gemini-triaged
angular/angular-cli#34130 · 1 personne assignée ·
Toutes les issues de angular/angular-cli
Issues similaires
-
S: triage
Difficulté 1/5 Moins d'une heure Accessibilité débutants 85/100
-
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 90/100
snapshot-labs/stamp#666 ·
-
fix(api): prevent leaderboard SSE heartbeat from starting after disconnect during initial load Ouvertebug
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
GauravKarakoti/SecureFlow#1070 · 1 commentaire ·
-
feature:Languages/Translations good first issue ready Web
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
digitalfabrik/integreat-app#4394 ·