Ao longo de anos construindo plataformas robustas (Dashboards, CRMs internos e E-commerces como desenvolvedor Full-Stack), a maior diferença entre um código de brinquedo e código corporativo é o nível de manutenibilidade.
React domina o desenvolvimento frontend, mas é notoriamente desprovido de opiniões a respeito da estrutura. Hoje, quero compartilhar como construo o esqueleto de uma SPA (Single Page Application) escalável.
1. Separação de Responsabilidades usando Custom Hooks
Componentes com milhares de linhas de código, misturando chamadas fetch com marcação HTML (<div/>), tornam-se incontroláveis a médio prazo.
Em projetos sérios, minha primeira regra é a separação de camadas:
- O Componente de UI renderiza apenas o estilo e as interfaces.
- A Lógica de Negócios reside separadamente em Funções de Serviço (Handlers, Utils).
- Custom Hooks atuam como orquestradores.
// Mau Exemplo (misturado)
function Dashboard() {
const [data, setData] = useState(null)
useEffect(() => { fetch('/api/data').then(...) }, [])
return <div>{data?.name}</div>
}
// Bom Exemplo (orquestrado)
function Dashboard() {
const { data, isLoading, error } = useDashboardMetrics()
if (isLoading) return <Spinner />
return <MetricsGrid renderData={data} />
}2. Tipagem Estrita (End-to-End TypeScript)
A tipagem “meia-boca” não serve para nada. Usar any elimina a vantagem fundamental do ecossistema TypeScript. Recomendo gerar interfaces automaticamente de acordo com o backend (ex. usando tRPC ou geradores OpenAPI), garantindo que se o banco de dados alterar um modelo, o nosso frontend reaja lançando um erro de compilação, e não no terminal do cliente durante um pico de tráfego.
3. Gestão de Estado: Quando NÃO usar Context
Existem inúmeras ferramentas disponíveis (Redux, Zustand, Context). Mas muitos cometem o erro de embutir o estado do servidor dentro de administradores de estado do cliente. Regra de Ouro:
- Para estado assíncrono (fetching, cache de banco de dados): Use React Query ou SWR.
- Para o estado efêmero de Interface (menu aberto, tema escuro): Zustand ou Context simples.
Adotar estes 3 princípios básicos de limpeza, separação negócio/UI e orquestração inteligente garante que, quando a equipe B2B precisar escalar sua aplicação de 5 para 50 desenvolvedores, a arquitetura não entrará em colapso.
