Services

• Services

Nomeação

Defina uma estratégia de nomeação entre sua equipe e respeite-a. Embora o guia de estilo Angular proponha não sufixar sistematicamente todos os serviços Angular, pois alguns nomes já falam por si mesmos como "Logger". Eu prefiro sufixar todos os serviços para que quando você ler LoggerService, você saiba que é um serviço, sem dúvidas!

O nome do arquivo também deve se expressar adicionando um serviço de ponto .service.tsa ele.

Função de serviço

• Princípio de responsabilidade única

Um serviço deve servir a um único propósito, uma vez que você tenha em mente que um serviço deve respeitar o princípio da responsabilidade única. Você terá um aplicativo mais limpo, fácil de ler por outros desenvolvedores e fácil de manter (tenho um problema com a autenticação = verifique o serviço de autenticação). Você identifica rapidamente onde está o problema, o princípio Identificar código em um piscar de olhos . O mesmo vale para os testes também.

• Lógica complexa

Componentes de contêiner ou componentes pai mantêm um mínimo de lógica que ele gerencia e, eventualmente, despacha dados/informações para seus filhos que são apenas componentes de apresentação, também chamados de componentes fictícios (mesmo que eu não goste do termo!). Ainda assim, um componente não deve ter lógica complexa porque já tem uma responsabilidade: o conteúdo que ele renderiza ao usuário, os dados que ele despacha para o componente filho, sua lógica simples, etc. Isso já é o suficiente. Um exemplo de coisas a serem evitadas em componentes são chamadas HTTP, isso é mais um trabalho de serviço. Um componente não deve obter os dados ou saber de onde eles vêm.

• Funcionalidades do serviço

Agora, existem diferentes maneiras de ver o princípio da responsabilidade única. Para alguns desenvolvedores, o Serviço deve conter apenas funções da responsabilidade/funcionalidade que possui, para que não injetem outros serviços no próprio Serviço. Eu não vejo assim. Se eu precisar pegar alguns dados do ProductService para usar no OrderService, por exemplo. Eu injetaria ProductService no meu OrderService. Qualquer lógica relacionada ao pedido ainda está no OrderService. Os dados do produto vieram do ProductService que já está isolado e usado aqui apenas para obter dados de entrada para usar nas funcionalidades do OrderService. Portanto, não estamos misturando as coisas aqui, o trabalho ProductService gira em torno de produtos, enquanto o OrderService gerencia coisas relacionadas a pedidos.

Injeção

Um serviço Angular deve ser injetado onde você deseja usá-lo. Então você precisa:

• Para tornar os serviços injetáveis adicionando o decorador @InjectableprovidedIn

  à sua classe. O

  aqui diz ao Angular para injetar este serviço no injetor raiz do aplicativo. O trabalho do injetor raiz é injetar serviços sempre que necessário.

• Então você o injeta em um componente. Recomenda-se usar esta sintaxe:

Ao invés disso:

A segunda opção é mais adequada caso o Serviço que você está injetando não esteja usando o tipo de dados de serviços como o token do Serviço.