React e componentização

Se você mantém um design system, você já é boa parte de um desenvolvedor React. Não na sintaxe, mas na única coisa que realmente é difícil: decidir o que vira componente, o que vira propriedade e o que é exceção que não deveria existir.

O React copiou esse modelo mental. As palavras são quase as mesmas, e as duas ou três que mudam, mudam pra melhor.

A tradução

A última linha é a interessante, e a gente chega nela.

Um componente é uma função que devolve interface

function Botao({ rotulo, variante = "primario" }) {
  return (
    <button className={`botao botao--${variante}`}>
      {rotulo}
    </button>
  );
}

E o uso:

<Botao rotulo="Salvar" />
<Botao rotulo="Cancelar" variante="secundario" />

Uma definição, duas instâncias. O = "primario" é o valor padrão: se ninguém passar, vem esse. É o mesmo conceito do valor padrão de uma property no Figma.

A restrição que melhora o sistema

No Figma, uma instância pode sobrescrever quase tudo do master. Você troca a cor, o texto, o ícone, o padding, e nada te impede.

No React isso não existe. O que pode variar precisa estar previsto como prop. Se você quiser um botão vermelho e não houver prop pra isso, ou você acrescenta a prop, ou não tem botão vermelho.

Parece limitação e é a coisa mais saudável do modelo, porque força a pergunta "o que neste componente é configurável?" a ter resposta escrita. É a mesma pergunta que você faz ao criar variants. A diferença é que aqui ela não pode ficar sem resposta.

Aliás, essa é uma tradução que vale levar de volta pro Figma: se um componente do seu sistema só sobrevive porque todo mundo faz override nele, ele está mal desenhado, e isso ia aparecer na hora de virar código.

Composição em vez de explosão de variants

Todo design system chega num componente com oito propriedades e trinta e duas combinações, das quais quatro são usadas.

O React resolve isso com children, que é o slot:

function Cartao({ children }) {
  return <article className="cartao">{children}</article>;
}

<Cartao>
  <h2>Título</h2>
  <p>Qualquer conteúdo aqui dentro.</p>
  <Botao rotulo="Abrir" />
</Cartao>

O cartão não precisa saber o que vai dentro dele. Ele cuida da borda, do padding e do fundo, e o conteúdo é problema de quem usa.

Isso muda o desenho: em vez de um Cartao com props temImagem, temBotao, temTag e temAvatar, você tem um Cartao com um buraco no meio. Menos props, menos combinação impossível, menos manutenção.

Quando você estiver na dúvida entre criar mais um variant ou abrir um slot, essa é a versão da pergunta que o código faz.

Estado, que é o que o Figma não tem

Estado é a informação que muda enquanto a pessoa usa a tela: o menu abriu, o campo tem texto, a lista carregou.

import { useState } from "react";
 
function Menu() {
  const [aberto, setAberto] = useState(false);
 
  return (
    <>
      <button onClick={() => setAberto(!aberto)}>
        {aberto ? "Fechar" : "Abrir"}
      </button>
      {aberto && <nav>...</nav>}
    </>
  );
}

Lendo em português: aberto é o valor atual, setAberto é como se muda ele, e useState(false) diz que começa fechado.

A diferença conceitual com o Figma vale parar um segundo. No Figma cada estado é uma tela desenhada, e o protótipo liga uma na outra. No React existe uma descrição só, e ela se ajusta ao valor. Você não desenha o menu aberto e o menu fechado como coisas separadas: você desenha o menu e diz o que aparece quando aberto é verdadeiro.

Por isso o inventário de estados que você faz no design vira, quase palavra por palavra, o inventário de estados do componente. E por isso vazio, carregando, erro, sucesso e cheio demais continuam sendo cinco casos que alguém precisa desenhar. Quem não desenha, delega.

Prop desce, estado nasce dentro

A confusão mais comum de quem está começando, e a regra é simples:

• prop vem de fora e o componente não altera
• estado nasce dentro do componente e muda com o tempo

Quando dois componentes precisam saber do mesmo valor, ele sobe pro pai mais próximo dos dois e desce como prop pra ambos. Isso tem nome (lifting state up) e é 90% das decisões de arquitetura que você vai ver num projeto de interface.

Nome de prop é decisão de design

<Alerta variante="erro" />     // bom
<Alerta cor="vermelho" />      // ruim

O primeiro sobrevive à próxima troca de identidade visual. O segundo vira cor="vermelho" num alerta que agora é laranja, e alguém vai ter que explicar isso pro próximo.

É exatamente a mesma regra de nomear token: nome ligado à intenção, não à aparência. Se você já faz isso no Figma, você já sabe nomear prop.

Hooks, em uma frase cada

Hook é uma função do React que começa com use e dá alguma capacidade ao componente. Os três que aparecem sempre:

Não precisa saber escrever. Precisa saber que quando você vê useEffect com fetch dentro, ali é o ponto onde os quatro estados de carregamento deveriam existir.

O que fazer hoje

Abre o seu design system e escolhe o componente mais usado. Botão serve.

Lista as propriedades dele e, pra cada uma, responde: isso é prop (configuração de fora), estado (muda durante o uso) ou slot (conteúdo que o componente não precisa conhecer)?

Vai aparecer pelo menos uma propriedade que existe só porque alguém precisou de uma exceção uma vez. Essa é a que vale conversar.

Você acabou de fazer o mesmo exercício que um dev faz antes de escrever o componente, com a mesma informação que ele tem. É por aqui que a conversa entre design e código deixa de ser handoff e vira desenho conjunto.

O próximo módulo é Next.js, onde esses componentes viram um site de verdade, com endereço e tudo.