Eu, você, nós todos já fizemos isso (ou continuamos). True?
Olha esse trecho de código a seguir:
...
<h2>{user.name}</h2>
<img src={user.avatar} alt="Avatar" />
...
Simples, inocente… e altamente perigoso.
Em ambientes reais, esse user provavelmente vem de uma API. E o que acontece quando a API falha, atrasa ou retorna um valor nulo?
💣 “Cannot read properties of undefined (reading ‘name’)”
🛡️ Programação defensiva na prática
Num projeto real, recebíamos dados de um usuário externo via API. Às vezes, o backend estava lento. Outras vezes, retornava incompleto. A solução?
Programação defensiva com TypeScript + Fallbacks:
O que mudou?
- Sem erros de runtime quando a API falha.
- A interface continua funcionando , mesmo com dados incompletos.
- Experiência do usuário protegida. Reputação da aplicação também.
📌 Algumas curiosidades nesse exemplo simples
- Tipagem : A definição de valores opcionais na tipagem vai ajudar a IDE a ti ajudar (linhas 4,5,9) ;
- Uso de FAIL FAST: Quanto mais cedo um usuário ou outro sistema for notificado que há um problema com o processamento de sua entrada, melhor ; (linha 14)
-
Operador || : Para que a imagem não quebre, uma vez que esse operador não só valida quando
user.avatar
for null ou undefined , mas também quando for falsy — como “” (string vazia), 0, false, NaN. (linha 18) - ?? (nullish coalescing operator): utiliza o texto default quando user.name for null ou undefined. (linha 19)
Conclusão
Assuma sempre que nada vai vir como o esperado (ou seja, não confie 100% no seu backend. srrsrs) — e seu código vai sobreviver ao caos da produção.
Recomendação de leitura de bolso
- https://deviq.com/practices/defensive-programming
- https://deviq.com/principles/fail-fast
- https://www.sciencedirect.com/topics/computer-science/defensive-programming
Curtiu? Arrocha um comments aí, sio.
Originally published at https://www.linkedin.com.
Top comments (0)