Quando Criar Hook Custom e Quando Parar

O problema

Uma das abstrações mais abusadas em frontend é o hook custom.

O raciocínio costuma ser:

• o componente cresceu
• está feio de ler
• vamos “tirar para um hook”

Só que isso não resolve o problema por si só.

Muitas vezes o resultado é:

• componente menor
• lógica igualmente confusa
• dependências escondidas
• nome bonito em cima de responsabilidade mal definida

Ou seja:

o arquivo ficou mais curto, mas o sistema não ficou mais claro.

Modelo mental

Hook custom não existe para reduzir scroll.

Ele existe para encapsular um comportamento que:

• se repete
• tem uma fronteira identificável
• ganha clareza quando exposto como API

Em frase curta:

extraia hook quando a abstração melhora o entendimento de quem usa. Não só quando melhora a estética de quem escreveu.

Quando costuma valer criar um hook

1. Quando há comportamento repetível

Exemplos:

• sincronizar query string com filtros
• lidar com paginação remota
• encapsular subscribe/unsubscribe
• coordenar loading, error e retry de um fluxo recorrente

Se isso aparece em várias telas com a mesma intenção, faz sentido nomear.

2. Quando existe integração chata que merece isolamento

Às vezes o problema não é repetição literal.

É o fato de existir uma integração verbosa ou barulhenta:

• observer
• listener
• media query
• analytics
• polling

Nesses casos, o hook pode servir para esconder detalhe incidental e deixar a tela falar mais do comportamento do produto.

3. Quando a API de uso fica melhor que a implementação original

Compare:

• um componente cheio de useEffect, useRef, cleanup e sincronização
• um useSearchResults({ query, page })

Se o nome da abstração ajuda a explicar a intenção, a extração pode ser boa.

Quando normalmente não vale

1. Quando o código ainda é específico demais daquela tela

Se o hook precisa conhecer:

• layout específico
• ids de tracking daquela página
• regra de navegação daquele fluxo
• detalhes visuais locais

então provavelmente ele ainda não é um hook reutilizável.

Ele é só lógica da tela tentando sair antes da hora.

2. Quando você está escondendo acoplamento

Tem hook que parece elegante até você abrir o arquivo e encontrar:

• fetch
• analytics
• navegação
• feature flag
• transformação de dados
• lógica de permissão

tudo junto.

Isso não é encapsulamento.

É acoplamento embalado.

3. Quando a abstração nasceu só para “limpar JSX”

Se a motivação principal foi:

• “o componente está grande”
• “ficou feio”
• “o PR parece melhor assim”

vale pausar.

Talvez o problema seja fronteira de responsabilidade, e não falta de hook.

Exemplo simples

Imagine uma tela de busca de usuários.

Versão ruim:

• a page lê query params
• faz debounce
• dispara fetch
• trata loading
• cancela requisição anterior
• loga analytics

Tudo dentro do componente.

Agora imagine que esse mesmo padrão aparece em outras telas.

Aí um hook como useSearchResults pode fazer sentido se ele:

• recebe entrada clara
• devolve estado claro
• encapsula o ciclo de busca
• não acopla detalhe visual

Mas se ele devolve quinze coisas e depende de metade do contexto da página, talvez ainda não estivesse pronto para existir.

Erros comuns

• Extrair hook antes de entender o comportamento estável.
• Criar hook para uso único e chamá-lo de reutilização.
• Colocar no hook tudo que era difícil de nomear no componente.
• Fazer hook esconder efeito colateral perigoso sem contrato explícito.

Como um senior pensa

Quem tem mais critério costuma perguntar:

• isso é uma abstração ou um esconderijo?
• outra tela conseguiria usar isso de verdade?
• a API ficou mais clara que a implementação original?
• estou removendo acoplamento ou só mudando ele de lugar?

Essa última pergunta evita muita abstração falsa.

Ângulo de entrevista

Esse assunto aparece bastante em:

• code review
• pair programming
• perguntas de arquitetura frontend

O entrevistador raramente quer ouvir “eu extrairia para um hook” como resposta automática.

Ele quer perceber se você sabe:

• por que extrair
• o que o hook deveria encapsular
• o que ainda deveria continuar na tela

Resposta forte costuma ter esse formato:

• primeiro nomeia o comportamento
• depois delimita a responsabilidade
• só então propõe o hook

Fechando a ideia

Hook custom bom dá nome, fronteira e interface para algo que já merecia existir.

Hook custom ruim é só um componente cansado tentando parecer arquitetado.

Se a abstração não melhora o entendimento de quem usa, ela ainda não pagou o aluguel.