Por que parei de colocar lógica de negócio dentro de componentes React

A primeira versão de qualquer recurso coloca a lógica ali mesmo, no componente. É rápido, é óbvio e funciona — até a segunda tela precisar da mesma regra e copiar, ou a regra mudar e alguém encontrar a terceira cópia dois meses depois.

Fui assim por um tempo: uma comparação de data aqui, um formato de moeda ali, uma checagem de status embutida no JSX. Cada uma inofensiva. Juntas, fizeram cada tela ficar levemente diferente das outras — e nenhuma errada de um jeito que um teste pegasse.

Minha regra é direta: componentes renderizam e capturam intenção; eles não decidem. Se um pedaço de código responde 'que estado de interface é esse?', pode viver no componente ou num hook. Se responde 'o que o negócio permite?', pertence a funções tipadas que não sabem nada de React.

O sistema de tipos trabalha mais aqui do que qualquer diagrama de arquitetura. Um status que é string com seis valores válidos é um bug esperando um typo; o mesmo status como union type torna metade dos estados inválidos impossíveis de escrever. O componente então vira a renderização de uma decisão que já foi tomada.

Regras de domínio ficaram testáveis sem renderizar nada. Refatorações deixaram de ser arqueologia. E os componentes ficaram chatos — que é o objetivo. Componente chato é aquele cujos bugs são de renderização, não de regras que ninguém lembra de ter escrito.

O framework importou menos do que eu esperava: a disciplina é a mesma se a visão é React ou outra coisa. A camada de visão é para tradução, não para política.