Variantes e modificadores transformam estilos em design system de verdade

Estilo decidido no ponto de uso é o problema

A tese central do artigo é que kits de interface que permitem passar qualquer estilo como prop - raio, tamanho, cor ou uma parede de classes utilitárias - incentivam decisões de estilo caso a caso, e isso impede a construção de um design system de verdade.

O autor demonstra o ponto com um botão escrito com Tailwind e outro com HTML puro: embora os mecanismos difiram (classes utilitárias ou atributo style), o resultado é o mesmo - o estilo é definido no ponto de chamada, instância por instância, em vez de ser nomeado uma vez e reutilizado. O mecanismo não importa; o autor chama isso de inlining.

Além dos problemas técnicos óbvios, como peso de página e cache, o autor aponta três problemas estruturais: não é possível garantir consistência visual, nem mesmo dentro de um único arquivo; o código não tem semântica, então não dá para dizer o que significa; e não há sistema por trás, o que dificulta a manutenção - inclusive com LLMs, já que esse estilo propenso a erros exige muitas iterações de correção.

Variantes: nomear o estilo uma vez

A primeira prática proposta é usar variantes: uma variante é o estilo autossuficiente que descreve completamente todos os aspectos visuais de um componente, sob um nome semântico. Em vez de escrever todas as classes inline, o consumidor escreve <Button variant="primary"> ou variant="secondary".

Uma regra essencial: a variante deve conter todos os detalhes de implementação visual - geometria interna, cores, tipografia - e não pode esperar complementação externa, seja de um reset global, de um font-family solto ou de qualquer estilo aplicado no local. É a variante que define a unidade semântica da interface, e é isso que torna um design system observável: dá para ver quais variantes de um componente existem e atualizar todas de uma vez.

Modificadores: variação controlada pela API

A segunda prática é o modificador. Em projetos grandes com design visual rico, é tentador escrever algo como variant="primary" radius="xl" fontSize="xl" fontWeight={500} - o que o autor considera o mesmo problema de estilo no ponto de chamada, apenas tipado: as props sobrescrevem a variante de fora, que deixa de definir o visual final do botão. Pior, essas sobrescritas não acompanham a variante: se ela for atualizada ou um novo esquema de cores for introduzido, os overrides ficam dessincronizados silenciosamente.

O modificador, em vez disso, é parte da API do componente, no mesmo nível da variante - não uma válvula de escape ao redor dela. O exemplo dado é <Button variant="primary" size="xl">, em que a variante controla o estilo visual e o modificador controla a geometria. Quando muitos modificadores acumulam, isso é sinal de que a combinação recorrente merece uma nova variante, como variant="fancy-primary".

O autor mostra a mesma regra em três tecnologias - CSS puro com modificador no estilo BEM, CSS modules no Mantine UI e tema com recipes no ChakraUI - para argumentar que variantes e modificadores funcionam independentemente das ferramentas usadas.

A disciplina como caminho para o design system

A conclusão é que variantes e modificadores não são apenas dois recursos de um kit de interface: são uma regra sobre onde uma decisão de estilo pode viver e quando uma combinação recorrente de modificadores ganha o próprio nome. Seguindo essa disciplina, mesmo sem partir para construir um design system, o time acaba com um - pois é forçado a identificar as unidades reutilizáveis da interface, e o código deixa de ser uma pilha de decisões avulsas de estilo para se tornar um sistema.