Angular-styleguide: Proposition : passer de « do » à « considérer » en ajoutant le suffixe « Service » aux classes Service (02-04) car cela n'améliore pas la clarté ou n'ajoute pas de valeur

@GUSCRAWFORD le guide de style officiel Angular a de bonnes raisons 😃 . Veuillez noter que ce ne sont pas des règles strictes, mais si vous me demandez, j'essaie de les suivre tous les jours, car elles sont écrites par des experts Angular 😏

@bampakoa Quelle a été la valeur de suivre 02-04 dans votre expérience ?

• Quel est un exemple d'inconvénient de ne pas le suivre ?
• Pourquoi est-il utile d'avoir un service explicitement nommé *er ou *Service

Pour ma part, pour jouer l'avocat du diable, le seul exemple de valeur qui me vient à l'esprit est l'implémentation de CanActivate , et il vaut la peine de savoir en regardant la structure du fichier que je n'injecte pas cela dans des composants ou d'autres services. Je pourrais facilement gérer cela avec la structure de répertoires aussi.

Si je vois une variable nommée User , je suppose qu'il s'agit d'une instance d'un modèle utilisateur ; Il aurait probablement des propriétés comme User.id , User.email , etc...

Inversement, si je vois une variable nommée UserService , je suppose qu'il s'agit d'un service ; Il aurait probablement des fonctions comme UserService.fetch() , UserService.update() , etc.

Je pense que cela améliore la clarté.

@GUSCRAWFORD En plus du commentaire de

• J'ai vu un énorme avantage lorsque je travaille en équipe avec d'autres développeurs ou même lorsque j'ai besoin de collaborer via plnkr ou codepen , éventuellement pour la reproduction d'un bogue.

• Un autre cas est celui où la base de code du projet s'agrandit et vous devez gérer de nombreux services. C'est vraiment pratique si vous pouvez repérer un service directement et ne pas avoir à fouiller dans les fichiers.

• En outre, cela aide les outils d'automatisation comme gulp à trouver ces services à l'aide de modèles regex et à faire tout ce qu'ils sont censés faire avec eux.

Il n'y a aucun mal à ne pas suivre les règles, vous allez toujours écrire en Angular :smiley: Il est vraiment utile que nous, en tant que développeurs Angular, _parlions_ le même langage et utilisions les mêmes notations dans notre codage quotidien.

@mattgrande Je serais presque d'accord, seulement quand je pense à moi-même en User , je sais à peu près que c'est un service si je l'utilise car c'est dans ma signature de constructeur où il est injecté.

@bampakoa :

• Dites-moi l'énorme avantage que vous avez eu à travailler avec une équipe et comment un xService explicitement nommé a dissipé la confusion ; Je peux certainement voir être plus illustratif dans un code-stylo
• Base de code croissante : ne séparez-vous pas les services dans un répertoire différent ? Ne devrais-je pas l'être aussi ? (Je ne suggère pas non plus de modifier la convention de nommage des fichiers)
• Donnez-moi un exemple (cas d'utilisation) d'utilisation de gulp pour trouver des services ? Je ne pensais pas que cela, j'ai trouvé ce (SJA) package intéressant mais un peu discutable avec les outils CLI;

:) Je n'essaye pas d'être trop pointilleux, mais là :

1. devrait être _quelque mal_ ou un inconvénient évident à ne pas suivre une règle de style, donc pas beaucoup de valeur sans elle
2. Je suis d'accord que nous devrions parler le même langage, mais DI est un concept plus large qui implique la notation Service sans jamais vraiment en avoir besoin.
3. Il ne s'agit pas de mes propres idiosyncrasies - si je reste en 02-04 et que j'utilise la CLI pour créer UserManager > ng g s user-manager je me retrouve avec UserManagerService malgré le er (les documents spécifient Logger comme bon exemple) étant un nom acceptable.
   
   
   
   • De toute évidence, User est également un nom techniquement acceptable trop malgré la confusion, d' autant plus à mon point pourquoi ne pas simplement simplifier et laisser tomber la recommandation du Service suffixe et recommande d'arrêter d' ajouter dans le cli
   
   

Je pense que c'est juste une frappe supplémentaire, et aucun avantage pour la lisibilité ou la clarté

Dites-moi l'énorme avantage que vous avez eu à travailler avec une équipe et comment un xService explicitement nommé a dissipé la confusion

Je pense que chaque équipe de développement devrait se conformer au même ensemble de règles dans le contexte du même langage. Dans notre équipe de développement front-end, qui se compose principalement de développeurs angulaires, nous devons comprendre rapidement le code source des uns et des autres au cas où nous en aurons besoin. Pensez à ce qui se passera, si j'utilise le suffixe Service , un autre utilise le suffixe SVC et un troisième aucun d'entre eux.
Je l'ai trouvé également utile lorsque j'ai besoin de jeter un œil dans une application après un certain temps. Vous n'avez pas à vous souvenir de ce que l'utilisateur a injecté dans votre composant 😃

Base de code croissante : ne séparez-vous pas les services dans un répertoire différent ? Ne devrais-je pas l'être aussi ? (Je ne suggère pas non plus de modifier la convention de nommage des fichiers)

Je préfère la structure dossier par fonctionnalité . Cela me permet de mieux comprendre la structure de ma candidature.

Donnez-moi un exemple (cas d'utilisation) d'utilisation de gulp pour trouver des services ? Je n'y avais pas pensé, j'ai trouvé ce package (AJs) intéressant mais un peu discutable avec les outils CLI ;

Il n'est pas encore nécessaire de l'utiliser dans mon cas, mais je sais qu'il sera là au cas où je devais le faire.

@bampakoa c'est une raison pour laquelle vous aimez la règle, ce n'est pas un exemple de règle évitant une confusion pour votre équipe. L'absence d'un exemple clair parle de mon point.

Ne séparez-vous pas les services liés aux fonctionnalités dans leur propre dossier, même au sein d'une fonctionnalité par dossier ?

Si je n'avais même jamais vu votre code ou le regardais pour la première fois, je pourrais en déduire les mêmes détails de la conception sans injectables nommés explicitement xService

Je veux générer des services avec le client et juste dans ce cas, l'ajout du suffixe de service au nom doit être explicite (c'est-à-dire Ng cli g "myService")