lume.books & ideiasPortfólio
Next.js — Aplicações full-stack com React e TypeScript
Capítulo 12/48 · Projeto 02 — Catálogo orientado a dados
Next.js — Aplicações full-stack com React e TypeScriptParte II — Servidor, cliente e dadosCapítulo 12 · Edição de estudo

Use os exemplos como laboratório: leia o código, preveja o resultado e teste no ambiente de prática. Para guardar uma ideia, selecione qualquer trecho.

CAPÍTULO 12 DE 48

Projeto 02 — Catálogo orientado a dados

Neste capítulo, você transforma DAL de leitura em uma decisão de engenharia full-stack que pode ser explicada, testada e revisada. Você sairá com uma implementação pequena, evidências de teste e um critério reutilizável nos projetos seguintes.

Parte II — Servidor, cliente e dados6 questões comentadasConceito · laboratório · projeto

Escrita, marcações e comentários ficam só neste navegador, separados por capítulo e sem sincronização com a conta. Evite informações sensíveis; limpar os dados do navegador pode remover seus registros.

02

Prepare-se — O que você vai construir

  • Explicar DAL de leitura sem depender de uma receita decorada.
  • Relacionar DTO mínimo ao contrato e ao fluxo observável.
  • Aplicar componente servidor em um caso real e em um limite.

Se precisar de apoio, consulte a capítulo anterior e volte a estas tarefas. Não há obrigação de seguir um prazo.

03

Entenda — Modelo mental e estrutura

1. Comece pelo modelo mental

O catálogo usa uma camada de acesso server-only, valida dados e devolve DTOs mínimos para páginas. Apenas busca e favoritos precisam de ilhas cliente. Em DAL de leitura, a sintaxe é apenas a superfície de um contrato. Relacione essa ideia a DTO mínimo e componente servidor antes de editar o exemplo. Em software real, uma linha pode compilar e ainda representar uma suposição incorreta sobre dados, tempo, ambiente ou responsabilidade. Por isso, descreva a entrada, a transformação e o resultado observável com palavras simples.

Descreva primeiro o contrato de DAL de leitura e como ele se relaciona com DTO mínimo. Implemente a menor versão que revele o mecanismo e mantenha o caminho principal fácil de seguir. Se a solução depende de estado implícito, conversão silenciosa ou ordem acidental, registre essa dependência e procure torná-la explícita. O objetivo não é memorizar uma receita: é reconhecer quando o conceito se aplica, escolher uma abstração proporcional e conseguir explicar o custo dessa escolha.

2. Leia o código como uma sequência de decisões

// data/produtos.ts
import 'server-only';
export async function listarProdutos(): Promise<ProdutoPublico[]> {
  const rows = await db.produto.findMany();
  return rows.map(toProdutoPublico);
}

Leia o exemplo de fora para dentro. Primeiro localize os dados e o contrato público; depois acompanhe as transformações; por fim, identifique efeitos, falhas e saídas. O trecho deixa DAL de leitura visível no código e permite evoluir componente servidor sem esconder o fluxo principal. Digite o trecho em vez de apenas copiá-lo. Troque nomes e valores, faça uma hipótese e execute novamente. Essa comparação mostra o que pertence à regra da linguagem ou do framework e o que existe apenas por causa do exemplo.

Observe também o que o código não garante. Next.js organiza renderização, rotas, dados e entrega; React descreve a interface; autorização e integridade permanecem responsabilidades explícitas do código de servidor. Um tipo estático não valida automaticamente uma resposta externa; um componente não substitui semântica; uma abstração não corrige um contrato mal definido. Comentários úteis registram intenção, limite ou motivo. Comentários que repetem a sintaxe não compensam nomes vagos ou responsabilidades misturadas.

3. Converta observação em critério verificável

Uma solução forte torna DAL de leitura legível, verifica DTO mínimo com evidência e registra os limites de componente servidor. Um bom critério descreve contexto, ação e resultado. Em vez de “funcionou”, registre qual entrada foi usada, qual saída era esperada e como uma falha deveria aparecer. Inspecione valores, mensagens e transições no Next.js 16.3.4, React 19.2, TypeScript e navegador. Quando houver interface, percorra também com teclado, zoom e tecnologia assistiva; quando houver servidor ou compilação, confira logs, tipos e limites de confiança.

A armadilha central é: transportar uma convenção antiga ou marcar tudo como cliente para contornar o contrato de DAL de leitura.. Corrija a causa antes de empilhar exceções. Reduza o caso, reproduza o problema, altere uma variável por vez e repita o teste. Ao terminar, você deve conseguir dizer por que a solução funciona, quais suposições preserva, onde pode falhar e que evidência outra pessoa pode usar para revisar a entrega.

04

Analise — Código em contexto

Uma revisão começa pela intenção. Para “Projeto 02 — Catálogo orientado a dados”, o requisito é: a solução deve demonstrar DAL de leitura, preservar DTO mínimo e reagir de forma previsível quando componente servidor variar. Analise a variação abaixo e preveja o resultado antes de executá-la.

export default async function Page() { return <Catalogo produtos={await listarProdutos()} />; }

A variação isola DTO mínimo. Acompanhe dados, controle e efeitos antes de decidir se o resultado respeita o contrato. Faça quatro passagens. Na primeira, identifique entradas e saídas. Na segunda, siga o fluxo de controle e as transformações. Na terceira, procure valores ausentes, concorrência, mutação e dependências do ambiente. Na quarta, avalie a experiência de erro e a capacidade de testar o trecho isoladamente.

Compare a variação com o exemplo principal. Escolha uma mudança e formule uma hipótese completa: “se eu alterar isto, espero aquilo, porque…”. Execute, observe e registre. A resposta importante não é apenas qual trecho passa no caso feliz, mas qual comunica melhor o contrato, reduz acoplamento e permanece compreensível para quem precisar manter, depurar ou integrar o módulo depois.

05

Construa — Teste cada decisão no ambiente

Crie um laboratório pequeno e executável em Next.js 16.3.4, React 19.2, TypeScript e navegador. Reproduza o exemplo, explique cada etapa e crie uma segunda versão que aplique componente servidor sem perder DAL de leitura. Primeiro implemente o caminho principal sem abstrações prematuras. Depois use o depurador, o verificador de tipos, os testes ou as ferramentas de inspeção adequadas para confirmar o fluxo. Por último, force três situações adversas: entrada vazia, volume maior que o esperado e falha controlada em Next.js 16.3.4, React 19.2, TypeScript e navegador.

Não corrija todos os sintomas de uma vez. Para cada falha, anote hipótese, evidência e menor mudança. Rode novamente os cenários já aprovados para detectar regressões. Quando houver mais de uma solução possível, escolha pela clareza do contrato, pela facilidade de teste e pelo custo de mudança. Uma captura ou um log ajuda a documentar, mas código, critérios e testes reproduzíveis continuam sendo a fonte principal da entrega.

06

Pratique — Seis decisões de implementação

Resolva primeiro pelo raciocínio. Consultar o capítulo e testar hipóteses no navegador faz parte do processo; depois, releia as justificativas.

E1 — Aplicar em contexto

Qual decisão inicia corretamente o trabalho de “Projeto 02 — Catálogo orientado a dados”?

E2 — Aplicar em contexto

Qual verificação oferece a evidência mais forte para este capítulo?

E3 — Aplicar em contexto

Qual prática deve ser evitada nesta implementação?

E4 — Aplicar em contexto

Qual escolha protege melhor quem usa ou integra o recurso?

E5 — Aplicar em contexto

Ao investigar um resultado inesperado, qual sequência é mais confiável?

E6 — Aplicar em contexto

Quando a entrega pode ser considerada pronta para revisão?

07

Confira — Gabarito comentado

Abrir gabarito e explicações completas

E1 — A. A implementação começa pelo contrato observável. Descreva primeiro o contrato de DAL de leitura e como ele se relaciona com DTO mínimo. Assim, a sintaxe passa a servir a uma decisão que pode ser revisada.

E2 — C. A evidência precisa exercitar o mecanismo estudado. Executar o caminho principal e os limites de DTO mínimo, observando o resultado de componente servidor. O caso feliz isolado não revela limites nem recuperação.

E3 — B. A armadilha é transportar uma convenção antiga ou marcar tudo como cliente para contornar o contrato de DAL de leitura. Ela oculta o mecanismo e amplia o risco de regressão quando dados ou requisitos mudam.

E4 — A. A alternativa correta inclui pessoas e integrações no contrato: Manter nomes, estados, foco e mensagens compreensíveis quando DAL de leitura chegar à interface. Estados e limites precisam permanecer compreensíveis.

E5 — C. A sequência baseada em evidência relaciona causa e efeito. Mudanças amplas escondem o mecanismo e dificultam perceber regressões.

E6 — B. Pronto para revisão significa atender critérios observáveis. O contrato de DAL de leitura está explícito, DTO mínimo foi exercitado e a falha de componente servidor produz um estado compreensível. Outra pessoa ainda pode encontrar melhorias, mas consegue reproduzir a evidência.

08

Projete — Implemente, compare e refine

Entrega incremental: um catálogo com DAL server-only, DTO público, lista e detalhe, busca cliente localizada e testes do mapeamento. Comece descrevendo, em até cinco linhas, quem usa o recurso e qual tarefa precisa concluir. Separe domínio, entrada e apresentação conforme a escala do problema. Inclua um caso real, um limite e uma falha recuperável. Ao final, escreva uma nota técnica explicando onde aplicou DAL de leitura, como verificou DTO mínimo e qual limite encontrou em componente servidor.

Consultar um modelo possível
// data/produtos.ts
import 'server-only';
export async function listarProdutos(): Promise<ProdutoPublico[]> {
  const rows = await db.produto.findMany();
  return rows.map(toProdutoPublico);
}

O modelo ilustra uma possibilidade. Use os critérios para revisar suas próprias ideias, não para copiar as mesmas frases.

Critérios para revisar

  • O contrato de DAL de leitura está explícito, DTO mínimo foi exercitado e a falha de componente servidor produz um estado compreensível.
  • Manter nomes, estados, foco e mensagens compreensíveis quando DAL de leitura chegar à interface.
  • O código evidencia DAL de leitura e DTO mínimo sem estado acidental.
  • A nota técnica registra o teste de entrada vazia, volume maior que o esperado e falha controlada em Next.js 16.3.4, React 19.2, TypeScript e navegador.

Até 12.000 caracteres em cada versão. Produção livre, sem correção automática.

09

Retome — Organize sua revisão

  • Explique com suas palavras a relação entre DAL de leitura e DTO mínimo.
  • Reabra o laboratório sem consultar o texto e reconstrua a decisão ligada a componente servidor.
  • Aplique o teste “Executar o caminho principal e os limites de DTO mínimo, observando o resultado de componente servidor.” ao projeto acumulado e registre uma melhoria.

Feche a explicação, tente lembrar um exemplo e depois confira. Retome uma dificuldade no próximo encontro e alguns dias depois; ajuste o intervalo ao que ainda precisa praticar.

Use exemplos concretos na autoavaliação: “consigo explicar com consulta” ou “quero praticar novamente”. Marcar como lida não representa uma certificação.

SEU PROGRESSO NO CAPÍTULO 12

Um capítulo, no seu ritmo.

— exercícios respondidos

Carregando progresso…

Você decide quando marcar este capítulo como lido. Isso não altera seus exercícios nem suas marcações.

Acompanhar todos os capítulos →

Progresso salvo só neste navegador, sem sincronização com sua conta.

Guardar uma ideia

Cor e significado

Você pode personalizar os significados no seu caderno.

Salvo só neste navegador, sem sincronização com a conta. Evite informações sensíveis em computadores compartilhados.

Do seu jeito de ler

Encontre o ritmo mais confortável para seus olhos.

Ambiente
Tipografia
Tamanho do texto
Entrelinhas
Largura da leitura

Preferências salvas neste navegador. O progresso indica a posição na página, não o domínio do conteúdo.

Seções do Capítulo 12