Não crie o componente reutilizável ainda: espere o padrão se repetir

O texto parte de um caso concreto: três fluxos de "item action" (aprovação, alteração e movimentação de itens) que tinham a mesma cara na interface, com lista, seleção, confirmação e resultado, mas comportamentos distintos. Aprovar é uma afirmação sobre o futuro, alterar acontece na hora, e mover depende de outro sistema que pode rejeitar o pedido. Ao unificar tudo num componente só, cada diferença virou uma flag. Mudar a confirmação passou a exigir acordo dos três responsáveis, de um revisor que conhecesse todos os modos e de testes para cada combinação de modo e variante.

A regra proposta é esperar o padrão aparecer três vezes pelo mesmo motivo de mudança. O teste do autor: se esse requisito mudar, quem eu consulto, e todas as cópias mudam juntas? Se a resposta varia por cópia, é coincidência, não duplicação. Formatador de data entra na extração, botões de envio de donos diferentes não. Devem ser compartilhados desde o início primitives estáveis (botões, text inputs, layout containers), design tokens, comportamento de acessibilidade (focus trapping em diálogos, navegação por teclado, labelling) e tudo guiado por padrão externo (datas, formatação de moeda, clientes de protocolo). O cheiro de abstração prematura aparece na lista de props: children, size, tone descrevem o que renderizar; mode, variant, isSpecial descrevem a situação. Para desfazer, faça inline do módulo em cada chamada, remova os ramos não usados e só depois extraia pedaços pequenos que mudam pelo mesmo motivo. O autor cita a regra de três atribuída a Don Roberts (no Refactoring, de Martin Fowler), Sandi Metz (The Wrong Abstraction) e a AHA programming de Kent C. Dodds.

Para quem mantém um design system ou uma base de componentes, a leitura é que a revisão de props vira um critério prático de code review. Se a API cresce em flags de contexto, o custo de coordenação entre times já está subindo, e o inline pode sair mais barato do que mais um modo.