Má prática de programação

Paulo, tudo bom?

Você poderia fazer uma sugestão de solução e apresentar aqui, o que acha?

Ou encaminhar a sugestão diretamente para a equipe da Alura.

Oi Paulo, dependendo da sua interpretação o termo API pode significar Web API (o conjunto de URLs de comunicação com o mundo externo), ou a API criada pelo conjunto de métodos da classe ApiService. Lendo o exercício e o capítulo em questão, vou assumir que sua interpretação é a segunda opção.

De fato, é chamado um método da classe ApiService para fazer uma chamada a uma URL externa e, na sequência, chamamos outro método da mesma classe ApiService para o tratamento de erros.

Perceba que essa estratégia tem como objetivo simplesmente centralizar a regra de tratamento de erros num único ponto do código, o que se torna uma prática bastante correta quando queremos, por exemplo, padronizar o tratamento dos mesmos códigos de resposta (401, 403...) em diversas URLs.

Num caso mais robusto, esse método de tratamento de erros poderia estar definido numa outra classe, ou até mesmo numa outra dependência.

É isso aí. Obrigado pelas respostas. Vi aqui que o próprio professor refatorou o código no primeiro vídeo da aula seguinte, exatamente corrigindo o que eu tinha reclamado. Também vi que o curso 3 é uma refatoração completa do projeto. Refatorar é bom, mas para melhorar o código. Não para corrigir más práticas que nem deveriam ter sido introduzidas. Sinto que estou perdendo um tempo precioso.

A título de curiosidade, eu não criei o método TratarErros como no exemplo e resolvi tudo no "cliente" mesmo:

carregarListaDeAutores() {
    APIService.listarAutores().then(resp => {
      if (resp.message === 'success') {
        this.setState({ listaDeAutores: resp.data })
      } else {
        alertarErro("Não foi possível carregar os autores já cadastrados.")
      }
    })
  }

O problema de resolver tudo no "cliente" (usando o mesmo termo da sua resposta) é o acúmulo de responsabilidades. Isso causa diversos problemas, dentre o quais temos:

• dificuldade de entendimento: muito código implica em mais coisas pra ler e entender na hora de fazer uma modificação.
• dificuldade para testar: muitos comportamentos encadeados torna difícil testar uma parte pequena de forma separada.

O código da sua última resposta é pequeno o suficiente para não haver problemas de entendimento, mas é bastante comum códigos gigantes começarem assim.

Então, é por isso que eu prefiro sempre extrair esses comportamentos para métodos menores, mais fáceis de entender, reutilizar e testar. Nesse caso, eu ficaria com o tratamento da resposta num método separado (talvez não na classe ApiService).

Entendi. Mas aí eu só tô atualizando a tela de acordo com a resposta recebida. O carregarListaDeAutores só faz isso e foi reusado dentro da própria página. E o alertarErro/Sucesso já foi componentizado.