Fotografia de capa por Miguel Salgado, tirada por uma Canon, EOS 7D
É extremamente fácil fazer interfaces usando componentes, depois que você entende o mecanismo básico dessa estruturação, você consegue criar e reutilizar código muito rápido, não é atoa que componentização se tornou o que é há bastante tempo.
Mas assim como CSS, que é muito fácil criar e difícil de manter, com componentes não é diferente, é muito fácil se tornar um caos por conta 2 duas coisas:
- Regras de "negócio" junto com camada de apresentação (entre aspas pois regras de negócio no front-end são só pra UX).
- Falta de tratamento de todos os estados.
O primeiro ponto é assunto pra um outro artigo, o segundo é o que vamos falar aqui.
Imagina você como dev front-end novato que acabou de subir uma feature para produção, deploy feito você valida que tudo está funcionando perfeito 🤩.
Porém a aplicação tem um pico de usuários que faz a API ficar retornando erro 503, ou seja, a api caiu e o front-end que você fez fica tudo em branco com vários e vários erros no console 🥺.
Quando a api volta, a tela de perfil de usuário também fica quebrada porquê no objeto de pegar usuário logado você esperava assim:
{
"name": "Igor",
"address": {
"city": "São Bernardo do Campo"
}
}mas por algum motivo tá retornando assim:
{
"name": "Igor"
}É bem comum pensarmos: "Eu não tenho culpa!"
É claro que tem! foge do seu controle o erro, mas você pode contornar do seu lado para melhorar para o usuário.
Existem 4 coisas que seu componente precisa ser capaz de lidar independente do tipo dele, elas são:
- Filled state: Seu componente precisa funcionar com todos os dados passados perfeitamente.
- Partial filled state: Seu componente precisa funcionar caso algum dos dados falte (exemplo do endereço acima é perfeito). Claro que existe um contrato entre back e front para ser consagrado, MAS sempre fique com o pé atras, ainda mais se front-enders e back-enders forem pessoas diferentes, pois aí entra comunicação e com comunicação entra ruído.
- Loading state: Front-end não é nada sem o back-end e vice-versa, o que torna as chamadas AJAX essenciais, nunca, mas NUNCA mesmo, esqueça de por um loading, caso contrário o usuário vai achar que é algum bug.
- Empty state: Com o componente sem dados, as piores coisas que podem acontecer é a tela ficar branca ou mesmo a interface quebrar. Prepare ele pra esse cenário!
- Error state: Erros são inesperados, e precisamos saber lidar com eles nos componentes também, precisamos trackear quando um erro acontece para setar coisas no state e resetar o que precisa ser resetado. Precisamos conseguir lidar com as coisas caso a api esteja down.
Siga essa práticas, que eu GARANTO que suas interfaces vão melhorar MUITO!