Para sistemas de design, consistência e compreensão são tudo. Um bom sistema de design garante consistência de implementação por meio da configuração do código que o implementa. Precisa ser:

• fácil de compreender sem abrir mão das nuances que um bom design exige;
• escalável e sustentável sem comprometer a consistência.

Usando minha pilha padrão de React com Tailwind, mostrarei como definir seus próprios padrões para tipografia, cor e espaçamento não é apenas o ponto de partida para diferenciar a aparência do seu aplicativo. Mais importante ainda, reduz drasticamente o código que temos que escrever e manter, o que reduz a carga mental de implementar estilos de forma sistemática, consistente e livre de erros.

Começarei com uma crítica importante que vejo o tempo todo e, em seguida, detalharei uma série de etapas de configuração que utilizo para resolvê-la.

Facilidade de uso não significa facilidade de conhecimento

Tailwind torna mais fácil para os desenvolvedores escrever estilos, o que é ótimo para prototipagem rápida. Mas essa facilidade não garante um bom design ou um sistema de design escalável e sustentável.

Padrões e ferramentas de configuração zero, como Tailwind, são a camada de ritmo de infraestrutura que cria mais tempo para construção. Mas se você estiver dimensionando um aplicativo que usa um sistema de design para se diferenciar, não poderá confiar apenas em configurações prontas para uso "grátis como no almoço".

Se você executar com a configuração padrão do Tailwind e enviar o gerenciamento de estilo para a aplicação de classes em componentes, o resultado geralmente será uma confusão de classes difíceis de raciocinar espalhadas pelos componentes, disfarçadas de um sistema de design.

Acima está um excelente exemplo. É quase ilegível e leva um tempo significativo para ser compreendido e muito menos manipulado. As tentativas de fazer isso têm grande probabilidade de levar à duplicação e ao erro, prejudicando a consistência do design em todo o aplicativo.

É fácil agrupar suas classes de design em um único className. Mas não há facilidade de conhecimento em fazer isso.

Configure seu sistema para facilitar o conhecimento

A facilidade de uso traz vantagens. Usar o padrão de outra pessoa significa confiar em seu conhecimento. Isto pode ser benéfico, mas também pode ser uma armadilha. Vamos dar um passo atrás e pensar sobre em que consistem os princípios básicos de um sistema de design:

• tipografia
• cor
• espaçamento
• capacidade de resposta (que inclui modo de cor)

No contexto do React with Tailwind, esses e muitos outros elementos do sistema de design são definidos na configuração do Tailwind, que podemos personalizar.

{/* mais bonito-ignorar */}

const config = {
  theme: {
    fontSize: { /* ... */ },
    colors: { /* ... */ },
    spacing: { /* ... */ },
  },
};

Padrões tipográficos

Você já se esforçou para lembrar o espaçamento correto entre letras em seu texto pequeno? E se você pudesse configurá-lo uma vez e esquecê-lo?

Podemos definir entrelinha (altura da linha) e rastreamento (espaçamento entre letras) como parâmetros para cada tupla de tamanho de fonte diretamente em tailwind.config. Isso significa que não precisamos definir entrelinhamento ou rastreamento quando usamos uma classe de tamanho de fonte. Não há necessidade de lembrar (ou deixar de procurar) qual é o espaçamento entre letras de texto pequeno.

fontSize: {
  small: [
    "13px",
    { lineHeight: 1.5, letterSpacing: "0.015em" },
  ],
  base: [
    "16px",
    { lineHeight: 1.5, letterSpacing: 0 },
  ],
}

O uso de texto pequeno agora define o tamanho da fonte, a altura da linha e o espaçamento entre letras. Colocar a tupla tipográfica principal em uma classe centraliza a implementação desses valores na configuração, em vez de em uma base de código. Uma grande vitória para a manutenção.

/* 13px/1.5 with 0.015em letter-spacing */

Padrões de cores

Podemos usar variáveis ​​CSS para definir cores responsivas nos escopos :root e html.dark. Isso significa que escrevemos e gerenciamos uma classe, como bg-canvas, em vez de duas, como bg-gray-100 dark:bg-gray-800.

@import "@radix-ui/colors/gray.css";
@import "@radix-ui/colors/gray-dark.css";

:root {
  --color-gray-base: var(--gray-1);
  --color-gray-bg: var(--gray-3);
  --color-gray-line: var(--gray-4);
  --color-gray-border: var(--gray-5);
  --color-gray-solid: var(--gray-10);
  --color-gray-fill: var(--gray-12);
}

Como estou usando Radix Colors aqui, não preciso definir o escopo .dark como isso já foi feito para mim. Se você não gosta das cores do Radix, pode personalizá-las, usar outra biblioteca ou escrever a sua própria.

Em seguida, defina as variáveis ​​​​CSS na configuração do Tailwind.

colors: {
  canvas: "var(--color-gray-base)",
  background: "var(--color-gray-bg)",
  line: "var(--color-gray-line)",
  border: "var(--color-gray-border)",
  solid: "var(--color-gray-solid)",
  fill: "var(--color-gray-fill-contrast)",
}

Usar bg-canvas agora define a cor apropriada no modo claro ou escuro. A remoção dessa duplicação em uma base de código centraliza o gerenciamento de cores em nossa configuração, em vez de espalhá-lo pela implementação de classes em componentes. Uma grande vitória para cognição e capacidade de manutenção.

/* sets --gray-1 as #fcfcfc on :root or #111111 on html.dark */

Nomenclatura semântica

Eu defendo nomes semânticos para cores e tamanhos de fonte porque a nomenclatura semântica é uma função forçada que vincula o significado ao uso. Fazer isso elimina suposições de implementação e reduz erros.

Já vi inúmeros projetos em que cinza-50, cinza-100 ou cinza-200 inconsistentes são usados ​​como planos de fundo. Isso é facilmente resolvido definindo uma cor chamada plano de fundo.

Da mesma forma, é mais fácil lembrar os nomes das cores claras e escuras do texto quando elas são chamadas de preenchimento e sólido. É mais difícil e mais sujeito a erros quando eles são chamados de cinza-900 e cinza-600, porque então você deve lembrar especificamente que não era cinza-950 e cinza-500, ou cinza-800 e cinza-700.

Mas nomear as coisas – e concordar em nomeá-las – é difícil. No espírito da configuração zero, sugiro adotar o paradigma de planos de fundo, bordas, sólidos e preenchimentos do Radix Color. Ou esta semântica de paleta.

E depois de definir isso em tailwind.config, o Typescript irá refrescar sua memória na ponta dos dedos com o preenchimento automático.

Evite conflitos de namespace

Se você estiver estendendo um tema do Tailwind e não estiver escrevendo o seu próprio, não use uma chave de escala que já tenha sido usada. Você pode substituir inadvertidamente uma classe que precisa usar.

Você notará no exemplo de configuração de cores anterior que defini a var --color-gray-base como tela, não como base. Se eu usasse base, usar essa escala de cores como cor de texto (base de texto) entraria em conflito com o valor base do tamanho da fonte padrão, que também é base de texto.

Isso não é uma desvantagem da personalização da configuração do Tailwind, é um legado de sua nomenclatura de tema: definir o tamanho da fonte ou classes de cor no Tailwind usa text-*.¹

Padrões de espaçamento

Também podemos usar variáveis ​​CSS para definir espaçamentos.

:root {
  --height-nav: 80px;
  --height-tab: 54px;
  --space-inset: 20px;
  --container-text-px: 660px;
  --container-hero-px: 1000px;
}

spacing: {
  em: "1em", /* relate icon size to parent font-size */
  nav: "var(--height-nav)",
  inset: "var(--space-inset)",
  text: "var(--container-text)",
  hero: "var(--container-hero)",
}

Pode-se argumentar que isso é excesso de engenharia. Exceto que quando chega a hora de calcular layouts interativos complexos, como cabeçalhos fixos, margens de rolagem e assim por diante, esse trabalho de configuração inicial o torna simples e livre de erros, até o pixel.

  

    /* ... */
  

Observe novamente que o uso de nomenclatura semântica facilita a lembrança e o uso.

Aumentando sua configuração do Tailwind

Agora configuramos tokens de tipografia, cor e espaçamento de uma maneira que seja fácil de entender e manter em um local único e centralizado. E não precisamos escrever tantas classes para implementar o sistema. Ganhar. E há outras medidas que podemos tomar para reduzir essa sobrecarga de implementação.

Fixe() suas classes

E se eu lhe dissesse que existe uma maneira de evitar completamente escrever text-lg lg:text-xl xl:text-2xl p-2 md:p-4 lg:p-8 em todos os lugares?

Podemos evitar a configuração de classes de tamanho de fonte responsivas usando clamp como um valor de tamanho de fonte em tailwind.config. Aqui está a função de fixação simples que uso.

fontSize: {
  title: [
    /* clamp(17px, 14.1429px   0.5714vw, 21px) */
    generateClampSize(500, 1200, 17, 21),
    { lineHeight: 1.5, letterSpacing: "-0.015em" },
  ];
}

Então, em vez de escrever text-lg lg:text-xl xl:text-2xl podemos apenas escrever text-title. Mais uma vez, ao elevar a capacidade de resposta do tamanho da fonte para um valor de fixação, evitamos novamente a armadilha das "classes de implementação", economizando esforço mental, erros e tempo de depuração.

Lembre-se de que isso significa que mudamos de text-lg lg:text-xl xl:text-2xl leads-none tracking-wide para text-title configurando corretamente o Tailwind. Vencendo!

/* 17px at 500px, 21px at 1200, fluidly calculated inbetween */
/* …with default line-height and letter-spacing also specified */

  Heading copy

Também podemos fazer isso para espaçamento. Ao estender um tema, eu prefixo essas teclas com d para "dinâmico" para diferenciá-lo da escala de espaçamento padrão.

spacing: {
  /* lower value is 2/3 of upper value */
  d4: generateClampSize(500, 1200, 10.5, 16),
  d8: generateClampSize(500, 1200, 21, 32),
  d16: generateClampSize(500, 1200, 43, 64),
  d24: generateClampSize(500, 1200, 64, 96),
  d64: generateClampSize(500, 1200, 171, 256),
}

Isso nos permite escrever py-d24 em vez de py-16 md:py-20 lg:py-24. Isso alivia o peso de manter em mente uma variedade de versões de sites para cada consulta de mídia. Em vez disso, incentiva-nos a imaginar layouts responsivos e fluidos, onde as medidas não importam tanto quanto os relacionamentos consistentes.

  

    /* ... */
  
  

    /* ... */
  

Resumo

IU bem elaborada é sua última defesa contra a onda descuidada de aplicativos de IA descuidados. Veja como personalizar o Tailwind pode economizar tempo e dores de cabeça para que você possa se concentrar na quantidade irracional de cuidado necessária para construir uma interface de usuário que funcione em um piscar de olhos:

• Use tailwind.config em todo o seu potencial. Centralize e agrupe seus tokens de design e evite a armadilha de "implementar classes em todos os lugares".
• Use clamp() para tipografia e espaçamento fluidos.
• Defina variáveis ​​de cor em :root e .dark para um modo escuro sem esforço.
• Nomeie as cores e o espaçamento semanticamente: o fundo supera o cinza-100 em qualquer dia.
• Relacione ícones ao tamanho do texto com size-em.

Sim, há um custo inicial de tempo. Mas compensa muito: menos código, menos erros, maior consistência de design e uma equipe que realmente entende o sistema.

A seguir: exploraremos como usar Class Variance Authority para criar uma API de estilo à prova de balas com acessórios semânticos extraídos do Tailwind. Fique atento.

1. É também por isso que não gosto de usar tailwind-merge para remover classes duplicadas do Tailwind em JSX. Na maioria das vezes, encontro a remoção de uma cor de texto em favor de um tamanho de fonte de texto quando ambos são necessários. Estou surpreso que mais desenvolvedores não levantem esse problema. ↩