Next.js App Router
Preserve a versão e configuração suportada da aplicação. Prefira renderização no servidor e leituras diretas do servidor quando adequado; mantenha comportamento interativo e ao vivo do navegador onde necessário.
Estabeleça o contexto
Inspecione package.json, o arquivo de lock, pastas de rotas, next.config.* e instruções do projeto. Identifique as versões instaladas do Next.js/React, App vs Pages Router, restrições de runtime/deploy e se Cache Components está habilitado. Em monorepos, resolva essas informações a partir da aplicação afetada. Não faça upgrade de pacotes ou habilite recursos apenas para se adequar a um exemplo.
Prefira documentação correspondente à versão que está em node_modules/next/dist/docs/ no Next.js 16.2+, quando disponível. Caso contrário, consulte a documentação oficial para a versão suportada. A documentação ao vivo pode descrever uma versão minor mais nova; confirme o histórico da versão da API e a configuração antes de usar. Distinga APIs estáveis, opções experimentais, depreciações e convenções do projeto.
Escolha o recurso relevante
Leia apenas os recursos necessários para a tarefa; siga seus links oficiais quando uma versão ou comportamento for incerto.
| Tarefa | Recurso |
|---|---|
| Limites servidor/cliente, composição, serialização | Server Components |
| Leituras, streaming, dados do navegador, ações, endpoints HTTP | Data fetching |
| Modo de cache existente, Cache Components, cache privado/remoto, invalidação | Caching |
| Layouts, rotas dinâmicas, busca, rotas paralelas/de interceptação | Routing |
| Redirecionamentos/reescritas de requisição e gates de autenticação otimistas | Proxy |
| Erros esperados, carregamento, recuperação, semântica de resposta 404 | Error handling |
| Exportações de metadados, herança e integração com SEO | Metadata |
| Configuração de imagem/fonte e tradeoffs de carregamento | Assets |
| Migração incremental de Pages para App | Migration |
| Upgrades deliberados de major/minor | Version changes |
Priorize decisões
- Proteja segredos e dados do usuário. Autentique e autorize leituras/mutações perto dos dados, valide entrada não confiável e mantenha dados pessoais fora de um cache compartilhado incorretamente. Proxy e visibilidade de UI não são autorização suficiente.
- Preserve a correção entre versões e modos de renderização. APIs de requisição assíncronas, pré-requisitos de cache, convenções de rota e props de recuperação dependem da versão/configuração instalada.
- Remova waterfalls demonstrados e código cliente desnecessário. Paralelize trabalho independente; escolha limites de Suspense que preservem uma UI útil. Busca no cliente permanece apropriada para polling, estado apenas do navegador e atualizações interativas.
- Ajuste cache, prefetch e dicas de ativos para frescor, implantação e comportamento medido. Essas são escolhas, não pré-requisitos para toda aplicação App Router.
Use Server Components para trabalho exclusivo do servidor. Adicione 'use client' em um limite de módulo útil para interação; não precisa ser uma folha. Use uma Server Action para mutações de UI quando apropriado, ou um Route Handler para um contrato HTTP (incluindo clientes de navegador). Nenhum substitui autorização.
Valide a mudança real
Execute os comandos de typecheck, lint e build existentes da aplicação afetada, quando disponíveis. Teste o comportamento que pode falhar: requisições diretas autenticadas, isolamento entre usuários, frescor pós-mutação, navegação hard/soft, erros e carregamento. Não considere um trecho pronto para produção quando imports, helpers de autenticação ou persistência forem placeholders. Informe o que foi executado e o que permanece não testado.
Para revisões, lidere com falhas acionáveis e seu escopo de versão/configuração. Separe melhorias opcionais de problemas de correção. Para implementação, explique o limite/modo de cache escolhido, o comportamento alterado e a verificação.
A revisão de fonte é focada, não uma certificação genérica. Veja SOURCES.md para links canônicos, versões/configurações aplicáveis, seções verificadas, datas upstream e a política de frescor. Os registros de revisão/avaliação piloto do repositório são evidências de manutenção e não são necessários em tempo de execução.