APRENDER. PRATICAR. EVOLUIR.O modo acompanha a disponibilidade dos dados
Client renderiza a aplicação no browser; Server produz HTML por pedido; Prerender gera documentos durante o build. Uma estratégia híbrida escolhe por rota em vez de impor a mesma decisão a todos os conteúdos. Artigos públicos conhecidos antecipadamente podem ser bons candidatos a prerender, enquanto dados por sessão exigem obtenção no momento adequado e isolamento.
A escolha influencia custo e experiência, mas não substitui medições no produto concreto. HTML produzido antecipadamente também não dispensa títulos, conteúdo substancial, status de resposta e política de indexação apropriados.
Enumerar rotas no build
getPrerenderParams fornece os mapas de parâmetros que identificam documentos a gerar para uma rota parametrizada. No exemplo, dois slugs produzem duas instâncias conhecidas de articles/:slug. Esta enumeração tem de usar informação disponível no build, não a identidade de um visitante futuro.
Mais parâmetros podem aumentar tempo de build e volume de ficheiros. Define também o comportamento para endereços que não foram enumerados segundo a configuração completa da aplicação. O exemplo delimita a lista conhecida e não implementa uma política completa para todos os possíveis slugs.
Código compatível com servidor e browser
Construir um componente no servidor não disponibiliza automaticamente window, navigator ou APIs de layout do browser. Trabalho que depende dessas APIs precisa de implementação adequada à plataforma ou inicialização num ponto exclusivo do browser, como afterNextRender.
Mantém a saída inicial coerente: escolher templates estruturalmente diferentes por uma condição de plataforma pode criar mismatch de hidratação. A solução não é apenas silenciar o erro de variável indefinida. Identifica os dados necessários ao primeiro HTML e o trabalho que pode ocorrer depois, quando o ambiente suporta a interação.
Hidratar exige correspondência estrutural
Hidratação restaura a aplicação no cliente reutilizando DOM produzido no servidor. A configuração provideClientHydration deve integrar os providers adequados no arranque do cliente e do servidor. A correspondência inclui estrutura, comentários e whitespace relevante, não apenas texto visível.
Um otimizador que remove nós ou uma biblioteca que os desloca antes da hidratação pode alterar o contrato. HTML inválido também pode ser corrigido pelo browser, produzindo uma árvore inesperada. Ao diagnosticar, compara a saída do servidor, a resposta após intermediários e a árvore encontrada no cliente.
Interações, estabilidade e soluções limitadas
Event replay conserva interações nativas suportadas ocorridas antes de a aplicação conseguir tratá-las e volta a apresentá-las após hidratação. Não é uma fila durável nem uma garantia de exatamente um commit remoto. A estabilidade da aplicação também condiciona fases de hidratação; perante atrasos, investiga trabalho pendente em vez de aceitar qualquer espera arbitrária. ngSkipHydration pode isolar um componente incompatível, mas só é válido no host de um componente e recria a respetiva subárvore.
Perdem-se benefícios de hidratação nesse âmbito; a causa estrutural continua a precisar de correção.
Estado por pedido e dados transferidos
Um objeto mutável configurado como useValue num provider top-level pode persistir entre pedidos no processo servidor. Se contém dados de utilizador, o âmbito está errado para isolamento por pedido. Uma factory adequada cria valores no momento e âmbito pretendidos.
O cache de transferência HTTP também precisa de análise: dados podem ser serializados no HTML inicial e reutilizados pelo browser até à estabilidade. As exclusões documentadas para credenciais e regras que proíbem caching não devem ser removidas indiscriminadamente.
Confirma quem recebe os dados e se a reutilização é permitida antes de alterar essa configuração.
Aceitação baseada em comportamentos observados
Para aceitar uma entrega, relaciona configuração com resultados: o documento inicial contém o conteúdo esperado, a rota representa a identidade correta, a hidratação conserva a interação e os dados privados ficam no âmbito autorizado. Exercita também falhas relevantes no ambiente apropriado e distingue observação de inferência.
O percurso ensina a interpretar estes contratos através de escolhas e cenários; não exige executar os excertos como avaliação. Uma configuração plausível ou um teste isolado não demonstra automaticamente desempenho, indexação real, acessibilidade integral ou segurança de todo o sistema.
// Reading example: server route configuration fragment, not a complete application.
import {ApplicationConfig} from '@angular/core';
import {RenderMode, ServerRoute, provideServerRendering, withRoutes} from '@angular/ssr';
export const serverRoutes: ServerRoute[] = [
{
path: 'articles/:slug', renderMode: RenderMode.Prerender,
async getPrerenderParams() {
return [{slug: 'routing-contracts'}, {slug: 'state-ownership'}];
},
},
{path: 'account', renderMode: RenderMode.Client},
{path: '**', renderMode: RenderMode.Server},
];
export const serverConfig: ApplicationConfig = {
providers: [provideServerRendering(withRoutes(serverRoutes))],
};
// Browser/server application routes, components, hydration setup and authenticated
// account API are configured separately; this fragment supplies none of those.Dois artigos públicos conhecidos são enumerados para prerender. account é renderizado no cliente e continua a precisar de uma API autenticada com autorização própria. As restantes rotas usam SSR. A configuração não implementa os componentes, não garante confidencialidade por escolher Client e não demonstra que a hidratação esteja instalada ou validada.
Armadilhas comuns
Prerender de informação personalizada sem isolamento; acesso a window durante SSR; alteração de nós por um intermediário; estado de utilizador em useValue global; cache de transferência indiscriminado; ngSkipHydration aplicado a qualquer elemento; inferir exatamente um efeito remoto de event replay.
Tópicos relacionados: Routing, estado e decisões de navegação · Fronteiras de segurança e conteúdo confiável · Testar comportamentos e limites de integração
Escolhe onde e quando renderizar, conserva a estrutura que será hidratada e limita a duração de dados por utilizador. A aceitação deve observar conteúdo, interação, isolamento e falhas dentro do ambiente relevante; configuração e contagens de testes são apenas parte dessa evidência.
Referência: Route-specific rendering · Angular 22; standalone components