JavaScript essencial

Até aqui a conversa foi confortável. HTML é a árvore de camadas, CSS é o painel de propriedades, e a tradução era quase palavra por palavra.

JavaScript é onde isso muda, e vale dizer logo em vez de fingir que não. O Figma tem um equivalente de layout e um equivalente de estilo. De lógica, ele só tem o protótipo, que liga tela A na tela B e para por aí.

A boa notícia é que a parte de JavaScript que aparece no seu dia a dia é pequena e repetitiva. São seis ideias. Depois delas você não escreve um sistema, mas lê o que a IA devolveu e sabe apontar o que está faltando, que é o objetivo.

1. Guardar um valor

const nome = "Danilo";
let contador = 0;

const é um valor que não vai ser trocado. let é um que vai. Na prática você vai ver const em quase tudo, porque a maior parte das coisas não muda depois de criada.

Os tipos que importam são poucos: texto (entre aspas), número, verdadeiro ou falso, e nada (null ou undefined).

Um detalhe que gera bug de interface: 0 e "" contam como falso quando testados. É a origem daquele card que some quando o valor é zero, ou do "0 itens" que não aparece.

2. Função, que é "entra isso, sai aquilo"

function formatarPreco(valor) {
  return valor.toLocaleString("pt-BR", {
    style: "currency",
    currency: "BRL",
  });
}
 
formatarPreco(1990); // "R$ 1.990,00"

Entra um número, sai um texto formatado. É isso que uma função é.

Você vai ver muito a forma curta, chamada arrow function, que faz exatamente o mesmo:

const formatarPreco = (valor) => valor.toFixed(2);

Vale saber que existe formatação nativa pra moeda, data e número, no idioma certo, sem instalar nada. Toda vez que você vê "R$ 1990.00" ou "07/08/2026" escrito na mão em algum lugar, é sinal de que alguém não sabia disso.

3. Lista e map, de onde vêm os cards

Um array é uma lista. E map é o que transforma cada item da lista em outra coisa:

const produtos = [
  { nome: "Processo detalhado", preco: 149 },
  { nome: "Mentoria", preco: 600 },
];
 
produtos.map((produto) => produto.nome);
// ["Processo detalhado", "Mentoria"]

Na interface, isso vira a lista de cards:

{produtos.map((produto) => (
  <Cartao key={produto.nome} {...produto} />
))}

Aqui tem uma tradução direta com o seu trabalho. Toda vez que você desenha um card e escreve "repetir para cada item", está descrevendo um map. E toda vez que pergunta "e se a lista vier vazia?", está lembrando de tratar produtos.length === 0, que é o estado vazio que quase sempre falta na entrega.

Os outros dois que aparecem sempre:

4. Condicional, que é o variant escolhendo sozinho

if (usuario.assinante) {
  mostrarConteudo();
} else {
  mostrarPaywall();
}

No Figma você desenha as duas telas e liga no protótipo. No código existe uma descrição só, que se ajusta ao valor.

A forma curta, que você vai ver dentro de interface o tempo todo:

{carregando ? <Skeleton /> : <Lista itens={itens} />}
 
{erro && <Alerta tipo="erro" mensagem={erro} />}

O ? lê como "se isso, então aquilo, senão aqueloutro". O && lê como "se isso, mostra aquilo, e se não, não mostra nada".

Reconhecer esses dois símbolos é o que separa "esse código é grego" de "ah, aqui é o estado de carregamento".

5. Evento, que é o protótipo de verdade

<button onClick={() => setAberto(true)}>
  Abrir
</button>

Um evento é algo que acontece na tela e um pedaço de código que responde. É a mesma ideia da interação do protótipo, com uma diferença que muda o desenho: no Figma o destino é uma tela, no código o destino é uma mudança de valor. E como a interface se ajusta ao valor, ela se redesenha sozinha.

Os que você vai ver:

E o detalhe de sempre: onClick num <button> funciona com mouse, com Tab mais Enter e com leitor de tela. O mesmo onClick numa <div> só funciona com mouse. Metade da acessibilidade de um controle vem de graça quando ele é um botão de verdade.

6. Espera, que é por que existe skeleton

Buscar dados demora. Enviar formulário demora. Subir imagem demora. O JavaScript lida com isso de forma assíncrona, o que quer dizer que ele não trava a página enquanto espera.

async function carregarProdutos() {
  const resposta = await fetch("/api/produtos");
  return resposta.json();
}

await é "espera essa parte terminar". E toda espera tem três destinos possíveis: ainda esperando, deu certo, deu errado.

Esses três não são detalhe técnico. São três telas:

• carregando: skeleton, spinner, botão com "Salvando..."
• sucesso: a tela que você já desenhou
• erro: mensagem que diz o que aconteceu e o que fazer agora

Some o estado vazio e você tem os quatro casos que todo componente que busca dado precisa. Quando o dev pergunta "e se der erro?", ele está pedindo a tela que falta, não criando problema.

O que isso muda na sua entrega

A tradução mais útil deste guia não é de sintaxe, é de processo:

Repare que quatro das cinco linhas você já faz. A que falta é a última, e ela custa uma frase por fluxo.

O que fazer hoje

Pega um fluxo do seu produto que busca dados. Qualquer um: lista de pedidos, resultado de busca, feed.

Escreve os quatro estados dele numa folha: carregando, vazio, erro, cheio. Se algum dos quatro não estiver desenhado, você achou trabalho de design que estava sendo decidido por outra pessoa, provavelmente às pressas, provavelmente na sexta.

Isso não exige escrever uma linha de JavaScript. Exige saber que os quatro existem, e agora você sabe.

O próximo módulo é React, que é onde essas peças viram componente e a conversa volta a ficar familiar, porque componentização é design system com outro nome.