Angular-styleguide: Propuesta: cambiar de "hacer" a "considerar" agregar el sufijo 'Servicio' a las clases de Servicio (02-04) porque no mejora la claridad ni agrega valor

@GUSCRAWFORD la guía de estilo oficial de Angular tiene algunas buenas razones 😃. Tenga en cuenta que estas no son reglas estrictas, pero si me preguntas, trato de seguirlas todos los días, ya que están escritas por expertos en Angular 😏

@bampakoa ¿Cuál ha sido el valor de seguir al 02-04 en tu experiencia?

• ¿Cuál es un ejemplo de un inconveniente de _no_ seguirlo?
• ¿Por qué es útil tener un servicio llamado explícitamente *er o *Service

Por mi parte, para jugar al abogado del diablo, el único ejemplo del valor que me viene a la mente es implementar CanActivate , y vale la pena saber, mirando la estructura del archivo, que _no_ estoy inyectando esto en componentes u otros servicios. También podría manejar eso fácilmente con la estructura de directorios.

Si veo una variable llamada User , supongo que es una instancia de un modelo de usuario; Probablemente tendría propiedades como User.id , User.email , etc.

Por el contrario, si veo una variable llamada UserService , asumiría que es un servicio; Probablemente tendría funciones como UserService.fetch() , UserService.update() , etc.

Creo que mejora la claridad.

@GUSCRAWFORD Además del comentario de @mattgrande :

• He visto una gran ventaja al trabajar en equipo con otros desarrolladores o incluso cuando necesito colaborar a través de plnkr o codepen , posiblemente para la reproducción de un error.

• Otro caso es cuando la base de código del proyecto crece y tienes que administrar muchos servicios. Es realmente útil si puede detectar un servicio directamente y no tener que buscar en los archivos.

• Además, ayuda a las herramientas de automatización como gulp a encontrar esos servicios utilizando patrones de expresiones regulares y hacer lo que se supone que deben hacer con ellos.

No hay nada de malo en no seguir las reglas, seguirá escribiendo en Angular: smiley: Es realmente útil que nosotros, como desarrolladores de Angular, _hablemos_ el mismo lenguaje y usemos las mismas notaciones en nuestra codificación diaria.

@mattgrande Casi estaría de acuerdo, solo que cuando pienso en mí mismo codificando con el ejemplo User , sé que es un servicio si lo uso porque está en la firma de mi constructor donde se está inyectando.

@bampakoa :

• Cuénteme la gran ventaja que tuvo trabajando con el equipo y cómo un xService con un nombre explícito aclaró la confusión; Ciertamente puedo ver ser más ilustrativo en un lápiz de código.
• Creciente base de código: ¿no está separando los servicios en un directorio diferente? ¿No debería ser yo también? (Tampoco estoy sugiriendo el cambio de la convención de nomenclatura de archivos)
• Dame un ejemplo (caso de uso) de usar gulp para encontrar servicios. No pensé en esto, encontré este paquete (AJs) interesante pero algo discutible con las herramientas CLI;

:) No estoy tratando de ser demasiado exigente, pero hay:

1. debería ser _alguno daño_ o un claro inconveniente de no seguir una regla de la guía de estilo, ergo no tiene mucho valor sin ella
2. Estoy de acuerdo en que deberíamos hablar el mismo idioma, pero DI es un concepto más amplio que implica la notación Service sin necesitarla nunca.
3. No se trata de mis propias idiosincrasias: si me quedo dentro de 02-04 y uso la CLI para crear UserManager > ng g s user-manager termino con UserManagerService pesar del er (los documentos especifican Logger como buen ejemplo) como un nombre aceptable.
   
   
   
   • Obviamente, User también es un nombre técnicamente aceptable a pesar de la confusión; más a mi punto, ¿por qué no simplificar y descartar la recomendación del sufijo Service y recomendar dejar de agregar en el cli
   
   

Siento que es solo una escritura adicional y no hay beneficio para la legibilidad o la claridad

Cuénteme la gran ventaja que tuvo al trabajar con el equipo y cómo un xService con nombre explícito despejó la confusión

Creo que cada equipo de desarrollo debería ajustarse al mismo conjunto de reglas en el contexto del mismo lenguaje. En nuestro equipo de desarrollo de front-end, que consiste principalmente en desarrolladores de Angular, debemos comprender el código fuente de los demás rápidamente en caso de que sea necesario. Piensa en lo que pasará, si utilizo el sufijo de servicio , otro usa el sufijo SVC y un tercero ninguno de ellos.
También lo he encontrado útil cuando necesito echar un vistazo en una aplicación después de un tiempo. No tienes que recordar qué es ese Usuario inyectado en tu componente 😃

Creciente base de código: ¿no está separando los servicios en un directorio diferente? ¿No debería ser yo también? (Tampoco estoy sugiriendo el cambio de la convención de nomenclatura de archivos)

Prefiero la estructura de carpeta por función . Me da una mejor comprensión de la estructura de mi aplicación.

Dame un ejemplo (caso de uso) de usar gulp para encontrar servicios. No pensé en esto, encontré este paquete (AJs) interesante pero algo discutible con las herramientas CLI;

No es necesario usarlo todavía en mi caso, pero sé que estará allí en caso de que tenga que hacerlo.

@bampakoa, esta es una razón por la que te gusta la regla, no es un ejemplo de la regla que evita una confusión para tu equipo. A falta de ella, un ejemplo claro hablará de mi punto.

¿No separa los servicios relacionados con funciones en su propia carpeta, incluso dentro de una función por carpeta?

Si nunca hubiera visto su código o lo estuviera mirando por primera vez, podría inferir los mismos detalles del diseño sin inyectables llamados explícitamente xService

Quiero generar servicios con el cliente y solo en este caso, agregar el sufijo del servicio al nombre debe ser explícito (es decir, Ng cli g "myService")