Angular, Buenas Prácticas de Desarrollo de Software

BUENAS
PRACTICAS
EN ANGULAR
Angular y .NET, arquitectura y buenas prácticas
Juan G Carmona
Angular y .NET, arquitectura y buenas prácticas © 2021 by Juan G Carmona is licensed under CC BY-NC 4.0
MÓDULO 2

Juan G Carmona
MÓDULO 2

Juan G Carmona
MÓDULO 2
 ESTRUCTURA FÍSICA
 ESTRUCTURA LÓGICA
 SINTAXIS
 PERFORMANCE
 SEGURIDAD
BUENAS PRACTICAS
EN ANGULAR

ESTRUCTURA
FÍSICA
Juan G Carmona
MÓDULO 2
BUENAS PRACTICAS
EN ANGULAR

Aplicar SRP en archivos
 SRP  Single Responsibility Principle
 Cada archivo tiene un único propósito  Responsabilidad
 Componentes
 Plantillas
 Servicios
 Pipes
 (etc)
 Nos permite crear un código limpio, legible y mantenible

Cuidar los nombres de archivos y
carpetas
 Los nombres deben seguir el mismo patrón, con la característica del archivo
en primer lugar, seguida del tipo, separados por un punto.
 Ej:
 dashboard.component.ts
 Auth.service.ts
 Si el nombre es compuesto utilizar ‘-’:
 Ej:
 article-list.component.ts
 cookie-consent.component.scss
 El nombre de una carpeta debe describir su contenido

Usar path alias
 Simplifican las rutas
 Código más fácil de leer y mantener.
 tsconfig.ts

Usar index.ts
 No es crítico, es recomendable
 Ayuda a mantener todos los archivos correlacionados en una única ubicación.
 Simplifica la importación porque no necesitamos recordar todas las rutas
 Imaginemos el módulo article, y dentro de él modelos, servicios, componentes…
 Imaginemos entonces este index.ts en src/modules/article
 Podríamos desde cualquier parte de nuestro código hacer algo similar a:

Estructura de carpetas adecuada
 Es una decisión crítica
 Debe tomarse antes de comenzar el proyecto
 Flexible y preparada para los cambios
“Have a near-term view of implementation and a long-term vision. Start
small but keep in mind where the application is heading.”
-- https://angular.io/guide/styleguide --
¿Qué aspecto tiene
esa estructura de
carpetas adecuada?
Mantener el código lo más cerca posible
de donde se usa es una buena práctica.

Juan G Carmona
MÓDULO 2
ESTRUCTURA
LÓGICA
BUENAS PRACTICAS
EN ANGULAR

Aplicar SRP en componentes
 Los componentes grandes añaden complejidad
 Dividirlos en otros más pequeños componentes reutilizables.
 Simplifica su gestión, mantenimiento y depuración
 Pero…
 ¿Qué tipo de componentes hay?
 ¿Cómo se comunican?
 ¿Cómo puedo hacer que mis componentes sean reutilizables?

Usar componentes listos y tontos
 LISTOS (SMART)
 Gestionan datos
 resolver | service | state
 Comunican hacia abajo
 Manejan/gestionan hacia arriba
 Niveles
 Páginas: DashboardPageComponent  dashboard-page.component.ts
 Views: ViewArticleComponent  view-article.component.ts
 TONTOS (DUMB)
 Reciben datos (@Input)
 Los presentan
 Emiten eventos (@Output)

Usar Variables de Entorno
 Múltiples entornos
 Múltiples configuraciones
 Por defecto
 Development
 Production
 Podemos añadir más
 Añaden seguridad
 Durante el desarrollo
 DevOps  Reemplazo al pasar a producción

Usar carga perezosa
 Aceleramos la carga inicial
 Retrasamos la carga de archivos concretos
 Strategias
 Lazy Loading
 Eager Lazy Loading
LAZY LOADING
ROCKS!

Usar un gestor de Estado
 REDUX es un patrón  Single Source of Trust
 Multiples librerías (NgRx, NGXS)
PATRÓN REDUX

Estrategia de módulos adecuada
 ¿Opciones?
 Todo en un módulo
 Un módulo por característica / vista (Lazy Laoding)
 Un módulo por componente (SCAM)
¿Cómo elegir
nuestra estrategia
de Módulos?

Juan G Carmona
MÓDULO 2
ESTRATEGIAS
PARA
MODULARIZAR
BUENAS PRACTICAS
EN ANGULAR

Estrategia de módulos adecuada
 ¿Opciones?
 Todo en un módulo
 Un módulo por componente (SCAM)
 Un módulo por característica / vista
Angular Modules Best Practices 2021 – by Christian Kohler

Todo en un módulo

Single Module output
 Desventajas:
 Tamaño
 Tiempo de carga
 Seguridad
 Mantenimiento
 Testing
 ¿Cuándo podemos utilizar esta estrategia?
 Aplicaciones muy pequeñas y simples
(por ejemplo PoC’s o DEMOS)

Un módulo por componente (SCAM)
Single Component Angular Module
 Lars Gyrup Brink Nielsen  SCAM

SCAM output
 Beneficios:
 Gestión de dependencias
 Tamaños
 Tiempo
 Patrón
 Desventajas:
 Demasiado boilerplate

Un módulo por característica (MPF)
 Es el patrón más común

MPF output
 Beneficios:
 Tamaño óptimo de paquetes
 Subdividible (jerarquía de módulos)
 Mejor mantenimiento
 NOTA: es el recomendado en la documentación oficial

¿Cuál elegir?
Angular Modules Best Practices 2021 – by Christian Kohler
 Para una librería parece preferible usar SCAM
 Para una app
 Si es muy simple
(< 10 componentes)  Single Module
 Si no: MPF | SCAM

¿Cómo afecta esto a nuestra estructura
de carpetas?

Juan G Carmona
MÓDULO 2
SINTAXIS
BUENAS PRACTICAS
EN ANGULAR

Seguir la guía de estilo
 Max 400 líneas por archivo
 Max 75 líneas por método.
 Convención con nombres de ficheros y clases "const" vs “let”
 Organización dentro de la clase
 Colocar las propiedades arriba, seguídas de los métodfos
 Colocar los métodos privados después de los públicos y
ordenados alfabéticamente
 Casing (camelCase vs PascalCase)
 (etc…) ;)
https://angular.io/guide/styleguide

Aprovechar las características de ES6
 Algunos de los aspectos más destacados:
 Clases
 Funciones flecha
 Template strings
 Herencia
 Ámbito de bloque en variables y constantes
 Spread operator and rest parameters (‘…’)
https://angular-training-guide.rangle.io/features/es6

Modo estricto
 Adaptarnos al modo estricto:
 strictNullChecks
 strictPropertyInitialization
 noImplicitAny
 (etcétera)
 https://angular.io/guide/strict-mode

Comprobación estricta de nulos
 Sin strict null checks
 Con strict null check

Inicialización de propiedades

Inicialización de propiedades
 ¿Y que hacemos con los Inputs()?
 “Property has no initializer and is not definitely assigned”

Evitar usar el tipo ‘any’
 Reduce el numero de errores inesperados
 Facilita nuestro refactor
 noImplicitAny: si y el compilador de TypeScript no puede inferir el tipo:
 genera los archivos JavaScript
pero también informa de un error.
 Poner atención en nuestras declaraciones de tipos:

Usar interfaces
 Debemos usar interfaces para crear los contratos para nuestras clases.
 Forzamos a que se implementen (o asignen) todos los atributos
 Si un objeto no incluye todas las propiedades el compilador nos dará un
error (y evitaremos sorpresas en tiempo de ejecución)

Palabras clave adecuadas
 var definimos una variable con local scope (función), también nos
permite utilizar un comportamiento llamado hoisting, sin generar
ningún error.
 let definimos variable con block scope (funciones, condicionales,
iteraciones), las variables declaradas de esta manera nos genera
un error de referencia cuando intentamos utilizar hoisting.
 const definimos variables de sólo lectura (no confundir con
inmutables), esto quiere decir que, cuando asignamos una
variable, el nombre de esta va estar asignada a un puntero en
memoria, el cual no puede ser sobreescrito o reasignado.
Hoisting is JavaScript's
default behavior of moving
declarations to the top.

Usar inmutabilidad
 Si queremos copiar un objeto a otro o a un array para modificarlo
tenemos que utilizar el operador ‘…’ (spread operator)
 De esta manera, estamos recreando el objeto y luego modificando
name.
 Clave para aplicar el patrón Redux (NgRx o NGXS) y optimizar la
detección de cambios en nuestros templates

Documentar el código
 Ayudará a otros desarrolladores a entender la lógica
 Mejora la legibilidad de un proyecto
 Los métodos deben definirse mediante comentarios de varias líneas
que indiquen qué tarea realiza realmente el método.
 Deben indicarse los parámetros y el valor de retorno.

Usar lint rules
 tslint (no-any, no-console, no-magic-numbers)  tslint.json
 Fuerza ciertas reglas que pueden ser personalizadas
 Consistencia
 Mi recomendación:
 Settings.json 
 Windows %APPDATA%CodeUsersettings.json
 macOS $HOME/Library/Application Support/Code/User/settings.json
 Linux $HOME/.config/Code/User/settings.json

Juan G Carmona
MÓDULO 2
SEGURIDAD
BUENAS PRACTICAS
EN ANGULAR

Prevenir vulnerabilidades de HTTP
 CSRF ó XSRF: cross-site request forgery
 XSSI: cross-site script inclusion

CSRF (Cross-site request forgery)
 Relevante si la autenticación se basa en cookies
 Hablamos de phising  enlaces o páginas web falsas con
acciones que benefician al atacante:
 Solución 1: csurf (Node.js) + HttpClientXssrModule  crea
un “firewall” con el servidor
 Solución 2: no basar nuestra autenticación (sólamente) en
cookies
 Solución 3: …
falsificación de peticiones entre sitios

XSS ó XSSI (Cross-site Script Inclusion)
 ¿De verdad queremos permitir que los usuarios inyecten “HTML”?
inclusión de secuencias de comandos entre sitios
https://jxxx.wordpress.com/

Nunca concatenar entradas de usuario
 No concatenar inputs de usuario con nuestros templates
 Sólo tiene sentido si el template es declarado desde el .ts
 Usar siempre interpolación ({{ user.input }})
 Minimizar el uso de InnerHTML (o prohibirlo)
 Si lo usamnos  sanitizar

Evita usar APIs arriesgadas de Angular
 ElementRef
 la API más arriesgada de Angular
 Proporciona acceso inmediato a los atacantes al DOM de nuestras páginas, lo
que hace que las aplicaciones sean aún más vulnerables a XSS.
 Además evitar:
 Node.appendChild()
 Usar el objeto ‘document’ para interactuar con nuestro DOM
 Usar jQuery!!!

Usar route guards
 canActivate
 canLoad
 Sólo se puede utilizar junto con Lazy Loading

Mantener nuestras librerías actualizadas
 Las actualizaciones no sólo traen innovaciones y mejoras
 Optimizaciones
 Resolución de Bugs
 Ojo con las librerías que usamos,
 aunque nosotros sigamos todas las buenas prácticas
 “quizá” otros autores no lo han hecho…

Juan G Carmona
MÓDULO 2
PERFORMANCE
BUENAS PRACTICAS
EN ANGULAR

Optimiza la detección de cambios
 ¿Qué?
 Cada componente angular tiene asociado un detector de cambios
 Para cada expresión en el template compara el valor actual de cada propiedad con el
valor previo y si son distintos se pone un flag a true  Se refresca
 ¿Qué podemos hacer?
 enum ChangeDetectionStrategy { OnPush: 0 Default: 1 }
 Default  verifica siempre
 OnPush  verifica una vez
 “When using OnPush detectors, then the framework will check an OnPush
component when any of its input properties changes, when it fires an event, or
when an Observable fires an event”

Prevenir memory leaks
 ¿Qué?
 Memory leak es memoria que ya no se utiliza pero que no se libera
 ¿Cómo?
 Si desde una instancia de una clase (por ej: un componente) nos suscribimos a
un Observable expuesto por un servicio o una clase diferente, creamos un
memory leak si no nos de suscribimos al destruir esa instancia.
 ¿Solución?
 ASYNC PIPE:
 TAKE UNTIL:

Evita suscripciones anidadas
 Técnicamente funciona:
 Es preferible concatenar
 Usando withLatestForm:
 Usando combineLatest
https://www.learnrxjs.io/

TrackBy + ngFor
 ¿Qué?
 Si hacemos 
 Se transforma en:
 Cada ngDoCheck que lanza la directiva ngForOf –> Angular busca cambios
 Por defecto:
 ¿Solución?
 Crear un trackBy personalizado. Por ejemplo:

Virtual Scrolling
 La carga de cientos de elementos puede resultar lenta en cualquier navegador;
 Simula todos los elementos que se van a renderizar (tamaño total y scroll)
 Solo renderiza los elementos que están a la vista

Minimiza la lógica en tus templates
 Técnicamente es correcto
 Aplica SRP
 Extrae esa lógica a componentes más pequeños
 Mejores pruebas unitarias
 Mejora el mantenimiento
 Cambios
 Reduce errores

Cachear llamadas a APIs
 …
 Se puede implementar una cache (con un diccionario)
 Se puede utilizar local-storage o sesión-storage
 Podemos beneficiarnos de NgRx Data (que ya cachea nuestras requests…)

Mejores métricas de rendimineto
 Time to Interactive (TTI)
 Tiempo hasta que la página es usable (y responde a acciones de usuario)
 First Contentful Paint (FCP)
 Tiempo hasta que el navegador muestra algo de contenido
 Visually Complete (VC)
 tiempo hasta que todo el contenido de la mitad superior de la página haya terminado
de renderizarse.
 Speed Index
 Tiempo desde TTFB hasta recibida la última carga (css, js, imágenes…)
 Time to First Byte (TTFB)
 Tiempo hasta la primera respuesta del servidor
 Total Content Size (TCS)

¿Cómo obtenemos métricas?
 Chrome Dev Tools
 Performance tab
 Ligihthouse

De forma general (a cualquier Web App)
Name Priority Comments
Minification High All file should be minified (HTML, CSS, JS)
Lazy loading High Images, scripts and CSS need to be lazy loaded to improve the
response time of the current page
DNS resolution High DNS of third-party services that may be needed are resolved in
advance during idle time using dns-prefetch.
Pre-connection Medium DNS lookup, TCP handshake and TLS negotiation with services that
will be needed soon is done in advance during idle time using
preconnect.
pre load & pre fetch Medium Pre loading & prefetching improves in TTI & FCP
webp format for serving
images
High
CSS bundle optimisation High use purge css to optimise css bundle
JS bundle optimisation High
Compression High
Caching static assets & using
CDN with larger expiry
High cache-control: max-age=2592000
Inlining Critical styles to
serve initial content fast
Medium Helps in FCP
Add inline styles for
application fonts & Serve
fonts from cdn
High
Service Workers Low Widely used with PWAs

Juan G Carmona
MÓDULO 2
Angular y .NET,
arquitectura y
buenas prácticas

Angular, Buenas Prácticas de Desarrollo de Software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (8)

Similar a Angular, Buenas Prácticas de Desarrollo de Software

Similar a Angular, Buenas Prácticas de Desarrollo de Software (20)

Angular, Buenas Prácticas de Desarrollo de Software

Notas del editor