Onde Page, Layout, Component e Hook Devem Decidir as Coisas

O problema

Muita arquitetura frontend degrada porque o time cria as camadas, mas não define o papel delas.

No papel existem:

• page
• layout
• component
• hook

Na prática, qualquer uma pode acabar fazendo qualquer coisa.

Aí aparecem sintomas previsíveis:

• page gigante decidindo detalhe de UI
• layout conhecendo regra de negócio
• component disparando busca, transformação e navegação
• hook escondendo acoplamento atrás de nome bonito

Modelo mental

Essas peças não existem para deixar a árvore mais bonita.

Elas existem para separar responsabilidades.

Em frase curta:

arquitetura frontend escala melhor quando cada camada decide só o tipo de coisa que faz sentido para ela decidir.

Não precisa ser uma regra religiosa.

Mas precisa existir uma intuição consistente.

Quebrando o problema

O papel da page

Page costuma ser um bom lugar para:

• compor a tela
• conectar contexto de navegação
• decidir fluxo principal
• alinhar dados de entrada daquela rota

Page normalmente não deveria carregar:

• microdetalhe visual
• regra genérica de layout
• lógica reutilizável enterrada ali sem motivo

O papel do layout

Layout é sobre moldura estrutural.

Exemplos:

• shell da aplicação
• barra lateral
• header
• áreas persistentes
• organização de regiões da tela

Quando layout começa a decidir regra específica de domínio, ele vira um ponto de vazamento.

O papel do component

Component é onde a UI concreta ganha forma.

Ele costuma ser um bom lugar para:

• renderização
• interação local
• composição visual
• pequenas decisões de comportamento imediato

O problema vem quando ele vira dono de:

• estratégia de busca
• regra transversal de domínio
• sincronização entre camadas demais

O papel do hook

Hook é útil quando existe comportamento repetível ou lógica de integração que faz sentido encapsular.

Ele não deveria existir só para “tirar código da tela”.

Sinais de hook bom:

• nomeia um comportamento real
• esconde detalhe incidental
• deixa quem usa com API mais clara

Sinais de hook ruim:

• virou gaveta de código solto
• mistura estado, fetch, analytics, navegação e regra de negócio sem critério
• só mudou o problema de arquivo

Exemplo simples

Imagine uma tela de faturamento.

Uma divisão mais limpa poderia ser:

• page decide qual conta está em foco e compõe a tela
• layout cuida da moldura comum do painel
• components renderizam tabela, filtros e blocos de resumo
• hook encapsula a lógica de paginação e carregamento da lista

Versão ruim:

• page faz fetch
• page transforma dados
• page decide estado visual
• page conhece navegação
• component conhece query params
• hook faz metade disso sem fronteira clara

Nesse cenário, o problema não é falta de abstração.

É abstração sem dono.

Erros comuns

• Criar hook para esconder volume, não para encapsular responsabilidade.
• Jogar no layout o que era decisão da tela.
• Transformar page em arquivo onipotente.
• Fazer component saber demais sobre backend e navegação ao mesmo tempo.

Como um senior pensa

Quem enxerga melhor arquitetura de frontend costuma perguntar:

• qual camada deveria saber disso?
• essa decisão é estrutural, visual, de fluxo ou de comportamento reutilizável?
• estou separando responsabilidade ou só espalhando código em mais arquivos?

Esse filtro costuma melhorar a base mais do que qualquer convenção de pasta.

O que isso muda no time

Quando as camadas param de competir entre si:

• a leitura melhora
• o reuso fica mais natural
• review fica menos ambíguo
• a evolução da tela exige menos escavação arqueológica

No fim, muita “arquitetura frontend” é só fronteira de decisão bem feita.

Se toda camada decide tudo, nenhuma camada ajuda de verdade.

Quando cada uma sabe seu papel, a base começa a respirar.