Senior React Frontend — Perguntas de entrevista React

O que realmente muda quando um componente vira um Server Component?

Ele roda só no servidor, então nunca envia JavaScript para o navegador e pode falar com um banco de dados diretamente, mas não pode ter state, usar effects, ou anexar handlers. O trabalho real de design é traçar a fronteira: as folhas interativas ficam como client components, e tudo acima delas pode ser server. Marcar um componente com "use client" torna tudo que ele importa também client, e é assim que os bundles silenciosamente param de encolher.

Sua app pontua mal em INP. Como você aborda isso?

INP mede o atraso entre uma interação e a resposta visual, então você procura tarefas longas na thread principal durante a interação. As causas usuais são uma atualização de estado que re-renderiza uma árvore grande, um handler síncrono caro, e a hidratação ainda rodando. As ferramentas são o Profiler e as entradas de long-task; as correções são reduzir o que re-renderiza, useTransition para atualizações não urgentes, e enviar menos JavaScript.

Como você decide o que pertence a um componente de design system versus à feature?

Um componente de design system possui aparência e interação que devem ser consistentes em todo lugar, e nada sobre uma feature específica. No momento em que ele ganha uma prop nomeada segundo uma tela, a fronteira foi cruzada. O teste é se um segundo time conseguiria usá-lo sem ler o código do primeiro, e se mudá-lo é um release coordenado em vez de uma edição local.

Um mismatch de hidratação aparece só em produção. Como você debuga isso?

Significa que o HTML do servidor e o primeiro render do cliente não coincidem, e as causas são uma lista curta: Date.now ou Math.random durante o render, ler localStorage ou window no caminho de render, formatação de locale ou fuso horário, e extensões do navegador reescrevendo o DOM. Reproduza com o render de produção localmente, depois faça bisseção suspendendo partes da árvore. Suprimir o warning é a correção errada — deixa as duas árvores de fato diferentes.

Quando um monorepo é a resposta certa para frontend, e quando é overhead?

É certo quando várias apps compartilham componentes e você quer uma mudança revisada e lançada em todas de uma vez, com as ferramentas — Turborepo ou Nx — para manter os builds incrementais. É overhead para uma app com um par de libs, onde você paga configuração de cache e complexidade de CI que não precisa. A pergunta decisiva é se mudanças cross-package acontecem toda semana ou duas vezes por ano.

Como você migraria uma base de código grande de class components para hooks?

Não como um projeto com prazo próprio. Converta ao tocar: qualquer componente alterado por uma feature é reescrito, então a migração viaja junto com trabalho que já ia acontecer. Comece pelas folhas em vez dos containers, já que elas têm menos lógica ao redor. Mantenha os dois estilos funcionando indefinidamente e aceite que alguns componentes nunca serão convertidos — o objetivo é uma base de código mais fácil de mudar, não um checklist completo.