Hoy publicamos la segunda parte de la traducción del artículo, que contiene un conjunto de recomendaciones para desarrolladores de Angular. En la
parte anterior se presentaron 11 consejos, en esto consideraremos la misma cantidad.
1. Pequeños componentes adecuados para reutilizar
Encuentre fragmentos en componentes que puedan reutilizarse y cree nuevos componentes basados en ellos. Haga que los componentes sean lo más tontos posible, ya que esto les permitirá ser utilizados en más escenarios. Un componente "estúpido" es uno que no contiene ninguna lógica específica, cuya operación depende únicamente de los datos de entrada que se le proporcionan.
Al trabajar con componentes, se debe cumplir la siguiente regla general: el componente anidado más profundo en el árbol de componentes también debe ser el más "estúpido".
▍ Explicaciones
La reutilización de componentes reduce la duplicación de código, lo que simplifica el soporte y los cambios del proyecto.
Los componentes estúpidos son más simples que otros, por lo que es menos probable que aparezcan errores en ellos. El uso de dichos componentes hace que el desarrollador piense mejor en la API abierta del componente y ayuda a resolver problemas.
2. Sobre las tareas resueltas por los componentes
Siempre que sea posible, evite la presencia en los componentes de la lógica que no sea la utilizada para visualizar datos.
▍ Explicaciones
Los componentes están diseñados como herramientas para presentar información y para controlar cómo deberían funcionar las interfaces. Cualquier lógica de negocios debe eliminarse de los componentes y colocarse, cuando sea posible, en métodos o servicios separados, separando así la lógica de negocios de la lógica de la presentación de información.
La lógica empresarial, cuando se presenta como servicios separados, suele ser más fácil de probar. Con este enfoque, puede ser reutilizado por diferentes componentes que necesitan las mismas capacidades.
3. Sobre los mejores métodos
Si el código del método resulta ser muy largo, esto generalmente indica que dicho módulo resuelve demasiados problemas. Tal método como entidad independiente, tal vez, resuelve solo un problema, pero dentro de él puede haber código que realiza varias operaciones diferentes. Dicho código puede emitirse en forma de métodos separados, cada uno de los cuales, nuevamente, debe resolver un solo problema, después de lo cual debe usar estos métodos en lugar de los fragmentos de código correspondientes en el método original.
▍ Explicaciones
Los métodos de código largo son difíciles de leer, comprender y mantener. Además, dichos métodos son propensos a errores, ya que cambiar uno de ellos puede afectar muchos otros mecanismos del método. El código largo significa una refactorización más complicada, y esta operación es muy importante en cualquier aplicación.
A este respecto, podemos mencionar un indicador como la
complejidad ciclomática del programa . Existen
reglas de TSLint para identificar la complejidad ciclomática que se puede usar en un proyecto para evitar errores que pueden aparecer en código que es demasiado complejo. Con su ayuda, puede evaluar la calidad del código y evitar posibles problemas con su soporte.
4. principio SECO
SECO (no repetirlo, no repetir) es un principio que debe seguirse para garantizar que en diferentes lugares del proyecto no haya copias de los mismos fragmentos de código. Dichos fragmentos de código deben hacerse en forma de entidades independientes, métodos, por ejemplo, y usar sus llamadas donde se usaba código repetido anteriormente.
▍ Explicaciones
Si se usa el mismo código en diferentes lugares de la aplicación, esto lleva al hecho de que si necesita hacer cambios a este código, tendrá que hacerlo en muchos lugares. Como resultado, el programa será más difícil de mantener, será propenso a errores relacionados, por ejemplo, al hecho de que no todos los fragmentos del mismo código fueron editados correctamente. Esto, además, aumenta el tiempo requerido para realizar cambios en el código y probarlo.
Si encuentra algo similar, formatee el código de repetición como una entidad independiente y úselo en lugar de repetir fragmentos. Esto conducirá al hecho de que para realizar cambios debe realizar ediciones en un solo lugar, y durante las pruebas deberá probar solo una pieza de código, no varias. Además, cuanto menos código duplicado haya en la aplicación, más rápido será descargado por los usuarios.
5. Mecanismos de almacenamiento en caché
Al realizar llamadas a varias API, notará que las respuestas de algunas de ellas casi nunca cambian. En tales casos, puede agregar herramientas de almacenamiento en caché de datos al programa y almacenar en la memoria caché lo que devuelven API similares. Al ejecutar la siguiente solicitud, puede recurrir a la memoria caché, y si ya tiene lo que necesita, puede usar estos datos, y si no la necesita, ejecute la solicitud real y coloque una respuesta en la memoria caché.
Si los datos recibidos de ciertas API cambian en algunos intervalos, puede almacenarlos en caché durante un tiempo determinado. Como resultado, al hacer una solicitud a tales API, será posible decidir de dónde obtener los datos necesarios.
▍ Explicaciones
Tener un mecanismo de almacenamiento en caché le permite evitar hacer solicitudes API innecesarias. Si las llamadas de la aplicación a la API se realizan solo cuando es absolutamente necesario, y los datos que la aplicación ya ha recibido no se vuelven a solicitar, el rendimiento de la solución mejora, en particular porque no tiene que esperar constantemente las respuestas de ciertos servicios de red. Este enfoque permite, además, ahorrar tráfico, ya que los mismos datos no se descargan una y otra vez.
6. Lógica en patrones
Si sus plantillas tienen al menos algo de lógica, incluso una simple expresión
&& , esta lógica debe extraerse y colocarse en el componente apropiado.
▍ Explicaciones
Si la plantilla tiene lógica, esto significa que dicha plantilla no puede someterse a pruebas unitarias y, por lo tanto, aumenta la probabilidad de errores al cambiar el código de la plantilla.
▍To
// <p *ngIf="role==='developer'"> Status: Developer </p> // public ngOnInit (): void { this.role = 'developer'; }
▍Después
// plantilla
<p * ngIf = "showDeveloperStatus"> Estado: desarrollador
// public ngOnInit (): void { this.role = 'developer'; this.showDeveloperStatus = true; }
7. Trabaja con líneas
Si tiene una variable de tipo de cadena, que puede tener valores de un conjunto limitado, entonces, en lugar de declararla como una cadena normal, especifique una lista de posibles valores al declararla.
▍ Explicaciones
Una descripción bien pensada del tipo de variable permite simplificar la detección y eliminación de errores, ya que con este enfoque se detectan en la etapa de compilación del programa y no en tiempo de ejecución.
▍To
private myStringValue: string; if (itShouldHaveFirstValue) { myStringValue = 'First'; } else { myStringValue = 'Second' }
▍Después
private myStringValue: 'First' | 'Second'; if (itShouldHaveFirstValue) { myStringValue = 'First'; } else { myStringValue = 'Other' } // Type '"Other"' is not assignable to type '"First" | "Second"' (property) AppComponent.myValue: "First" | "Second"
8. Acerca de la gestión del estado de la aplicación
Considere usar
@ ngrx / store para controlar el estado de su aplicación y
@ ngrx / effects para implementar efectos secundarios. Los cambios de estado se describen mediante acciones y se realizan mediante funciones puras llamadas reductores.
▍ Explicaciones
@ ngrx / store aísla la lógica relacionada con el estado de la aplicación en un lugar y la hace uniforme en todo el proyecto. Aquí, además, hay un mecanismo de memorización que funciona cuando se trabaja con almacenamiento, lo que mejora el rendimiento de la aplicación. El mecanismo @ ngrx / store, combinado con la estrategia de detección de cambios de Angular, conduce a aplicaciones más rápidas.
9. Sobre la inmutabilidad del estado de la aplicación
Cuando use @ ngrx / store, considere usar la
biblioteca ngrx-store-freeze para hacer que el estado de la aplicación sea inmutable. Esta biblioteca previene mutaciones de estado lanzando excepciones. Esto evita cambios accidentales en el estado de la aplicación que conducen a consecuencias impredecibles.
▍ Explicaciones
Cambiar el estado de la aplicación en los componentes conduce al hecho de que el comportamiento de la aplicación cambia según el orden en que se cargan los componentes. Esto viola el modelo mental de la plantilla redux. Como resultado, los cambios se pueden redefinir si el estado del repositorio cambia y el trabajo posterior con él ya está utilizando el nuevo estado. Aquí aplicamos el principio de separación de responsabilidades, según el cual los componentes están en el nivel de presentación y no deben saber cómo cambiar el estado de la aplicación.
10. Herramientas de prueba de aplicaciones
Use herramientas especializadas para probar aplicaciones. Entre ellos están
Jest y
Karma .
▍ Explicaciones
Jest es un marco de aplicación de prueba de unidad desarrollado por Facebook. Admite mecanismos de ejecución de pruebas paralelas, lo que acelera el trabajo. Debido al hecho de que es capaz de tener en cuenta los cambios en la base del código, en la próxima sesión de prueba solo se realizan pruebas relacionadas con el código modificado. Esto mejora la capacidad de analizar los resultados de la prueba. Además, Jest proporciona métricas de cobertura de prueba y es compatible con el editor de código VS y el IDE de WebStorm.
El corredor de prueba de Karma fue desarrollado por el equipo de AngularJS. Para ejecutar las pruebas, necesita un navegador real y DOM. Karma le permite ejecutar pruebas en varios navegadores. Jest, a su vez, no necesita, por ejemplo, un navegador Chrome sin una interfaz de usuario o phantom.js, ya que solo se necesita la plataforma Node.js para que este marco funcione.
11. Representación del servidor
Si aún no ha utilizado
la tecnología
Angular Universal , ahora es el momento de probarla. Le permite organizar la representación del lado del servidor de aplicaciones angulares. Como resultado, se envían al usuario páginas HTML estáticas y previamente renderizadas. Esto hace que las aplicaciones sean increíblemente rápidas, ya que su contenido aparece en los navegadores casi instantáneamente debido al hecho de que el navegador no tiene que descargar y analizar paquetes JS y perder tiempo asegurando el funcionamiento de los mecanismos angulares.
Además, las aplicaciones angulares representadas en el servidor tienen ventajas sobre las aplicaciones regulares en términos de CEO. Angular Universal crea páginas estáticas, y esto facilita que los motores de búsqueda indexen dichas páginas, ya que no tienen que ejecutar código JavaScript para formar páginas.
▍ Explicaciones
El uso de Angular Universal puede mejorar drásticamente el rendimiento de la aplicación. Recientemente, actualizamos nuestra aplicación, agregando capacidades de representación del servidor. Esto ha llevado a una reducción en el tiempo de carga del sitio de unos pocos segundos a decenas de milisegundos.
Además, gracias a este enfoque, las páginas se muestran correctamente en las áreas de vista previa de contenido utilizadas en las redes sociales. El tiempo para la primera visualización de página significativa (Primera pintura significativa) es muy corto, lo que evita que los usuarios esperen innecesariamente.
Resumen
El desarrollo de aplicaciones es el camino a través del cual el programador encuentra constantemente oportunidades para mejorar lo que crea. Usted, siguiendo este camino, puede aprovechar los consejos que se dan aquí para optimizar las aplicaciones de Angular. Estamos seguros de que su aplicación consistente beneficiará a cualquier equipo de desarrollo y que el resultado resultante atraerá a los usuarios, ya que, desde su punto de vista, esto conducirá al hecho de que trabajarán con aplicaciones más estables y productivas.
Estimados lectores! Si puede compartir consejos útiles para mejorar las aplicaciones con la comunidad de desarrolladores de Angular, hágalo.
