Passo 2: Validando antes de gastar uma requisição
Nem todo texto digitado é um CEP válido. Checar isso no seu próprio código, antes de sair buscando na internet, poupa uma viagem inteira até o servidor.
Estudar esta lição interativa →Antes de sair buscando na internet, vale a pena perguntar: esse texto digitado sequer parece um CEP? Um CEP brasileiro tem 8 dígitos (às vezes digitado com um traço no meio, como 01310-930). Duas funções pequenas cuidam disso: limparCep(texto), que usa a expressão regular /\D/g ("tudo que não é dígito", globalmente) para arrancar traços, espaços e qualquer outro caractere que não seja número; e cepValido(cep), que só confere se o texto limpo tem exatamente 8 caracteres.
Por que checar isso antes de qualquer fetch? Porque uma requisição de rede é uma viagem de verdade até um servidor, ida e volta, e pode levar segundos. Gastar essa viagem inteira só para descobrir que o CEP tinha 5 dígitos é um desperdício que seu próprio código já sabia evitar. Esse hábito, validar o que der para validar localmente antes de envolver a rede, aparece em praticamente todo formulário sério da web.
🧩 Este conteúdo é interativo — abra no app para ver e rodar de verdade. Digite um CEP incompleto e clique em Buscar: o app reclama sem nunca sair para a internet. Digite 8 dígitos e veja a confirmação.
Repare que as duas funções só recebem texto e devolvem texto ou booleano, sem ler nem escrever em nenhum elemento da página. É a mesma disciplina de "lógica pura separada do DOM" que você já praticou em calcular(), totalCarrinho() e verificarPar() nos projetos anteriores, e é exatamente o que torna essas duas funções testáveis no desafio final deste módulo, sem precisar simular nenhuma requisição de rede.