Angular-styleguide: Proposta: mudar de "fazer" para "considerar" adicionando o sufixo 'Serviço' às classes de Serviço (02-04) porque não melhora a clareza nem agrega valor

@GUSCRAWFORD o guia de estilo oficial do Angular tem alguns bons motivos 😃. Observe que essas regras não são rígidas, mas se você me perguntar, tento segui-las todos os dias, já que foram escritas por especialistas angulares 😏

@bampakoa Qual foi o valor em seguir 02-04 em sua experiência?

• Qual é um exemplo de desvantagem de _não_ segui-lo?
• Por que é útil ter um serviço denominado explicitamente *er ou *Service

De minha parte, para bancar o advogado do diabo, o único exemplo de valor que vem à mente é a implementação de CanActivate , e vale a pena saber olhando para a estrutura do arquivo que _não_ estou injetando isso em componentes ou outros serviços. Eu poderia facilmente gerenciar isso com a estrutura de diretórios também.

Se eu vir uma variável chamada User , presumo que seja uma instância de um modelo de usuário; Provavelmente teria propriedades como User.id , User.email , etc ...

Por outro lado, se eu vir uma variável chamada UserService , presumo que seja um serviço; Provavelmente teria funções como UserService.fetch() , UserService.update() , etc.

Acho que melhora a clareza.

@GUSCRAWFORD Além do comentário de @mattgrande :

• Tenho visto uma grande vantagem ao trabalhar em equipes com outros desenvolvedores ou mesmo quando preciso colaborar por meio de plnkr ou codepen , possivelmente para a reprodução de um bug.

• Outro caso é quando a base de código do projeto cresce e você tem que gerenciar muitos serviços. É muito útil se você puder identificar um serviço diretamente e não precisar vasculhar os arquivos.

• Além disso, ajuda as ferramentas de automação, como o gulp, a encontrar esses serviços usando padrões regex e a fazer o que for necessário com eles.

Não há mal nenhum em não seguir as regras, você ainda estará escrevendo em Angular: smiley: É realmente útil que nós, como desenvolvedores Angular, _falemos_ a mesma linguagem e usemos as mesmas notações em nossa codificação diária.

@mattgrande Eu quase concordaria, só que quando penso em mim mesmo codificando com o exemplo User , sei muito bem que é um serviço se o usar porque está na assinatura do meu construtor onde está sendo injetado.

@bampakoa :

• Conte-me a grande vantagem que você teve em trabalhar com a equipe e como um xService explicitamente chamado esclareceu a confusão; Eu posso certamente ver sendo mais ilustrativo em uma caneta de código
• Base de código crescente: você não está separando os serviços em um diretório diferente? Eu também não deveria? (Não estou sugerindo a mudança na convenção de nomenclatura de arquivo)
• Dê-me um exemplo (caso de uso) de uso do gulp para encontrar serviços? Não pensei nisso, achei este pacote (AJs) interessante, mas meio discutível com as ferramentas CLI;

:) Não estou tentando ser muito exigente, mas tem:

1. deve ser _algo_ ou uma clara desvantagem de não seguir uma regra do guia de estilo, portanto, não tem muito valor sem ela
2. Eu concordo que deveríamos estar falando a mesma língua, mas DI é um conceito mais amplo que implica a notação Service sem realmente precisar dela.
3. Não se trata de minhas próprias idiossincrasias - se eu ficar entre 02-04 e usar a CLI para criar UserManager > ng g s user-manager acabo com UserManagerService apesar de er (documentos especificam Logger como um bom exemplo) sendo um nome aceitável.
   
   
   
   • Obviamente, User também é um nome tecnicamente aceitável, apesar da confusão - tanto mais ao meu ponto, por que não simplificar e descartar a recomendação do sufixo Service e recomendar parar de adicionar no cli
   
   

Eu sinto que é apenas uma digitação extra e nenhum benefício para a legibilidade ou clareza

Conte-me a grande vantagem que você teve ao trabalhar com a equipe e como um xService com nome explícito esclareceu a confusão

Acho que toda equipe de desenvolvimento deve estar em conformidade com o mesmo conjunto de regras no contexto da mesma linguagem. Em nossa equipe de desenvolvimento de front-end, que consiste principalmente de desenvolvedores Angular, precisamos entender o código-fonte uns dos outros rapidamente, caso seja necessário. Pense no que vai acontecer, se eu usar o sufixo de serviço , outro usa o sufixo SVC e um terceiro nenhum deles.
Também achei útil quando preciso examinar um aplicativo depois de algum tempo. Você não precisa se lembrar o que é que o usuário injetou no seu componente 😃

Base de código crescente: você não está separando os serviços em um diretório diferente? Eu também não deveria? (Não estou sugerindo a mudança na convenção de nomenclatura de arquivo)

Eu prefiro a estrutura de pasta por recurso . Isso me dá uma melhor compreensão da estrutura do meu aplicativo.

Dê-me um exemplo (caso de uso) de uso do gulp para encontrar serviços? Não pensei nisso, achei este pacote (AJs) interessante, mas meio discutível com as ferramentas CLI;

Não há necessidade de usá-lo ainda no meu caso, mas sei que estará lá caso seja necessário.

@bampakoa esse é um motivo pelo qual você gosta da regra, não é um exemplo da regra evitando confusão para o seu time. Falta de um exemplo claro para falar ao meu ponto.

Você não separa os serviços relacionados a recursos em suas próprias pastas, mesmo dentro de um recurso por pasta?

Se eu nunca tivesse visto seu código ou estivesse olhando para ele pela primeira vez, poderia inferir os mesmos detalhes do design sem injetáveis ​​explicitamente chamados de xService

Quero gerar serviços com o cliente e, apenas neste caso, adicionar o sufixo do serviço ao nome deve ser explícito (ou seja, Ng cli g "myService")