Últimamente he trabajado ya como “Developer de Angular” directamente, y con gente que sabe de Angular, pero he notado que hacen ciertas cosas que no deberían hacerse, por lo que por ahora les quiero compartir 3 cosas que se deben evitar a la hora de trabajar con Angular (aunque ojo, no necesariamente está mal hacerlo).
Lo primero es que debes evitar tener cosas que sean “recurrentes sin necesidad”, ¿a qué me refiero?, bueno, en el mundo de Angular, si por ejemplo haces una petición HTTP que pueda tardar digamos 30 segundos, y un usuario cambia fuera de ese componente que estaba realizando la petición, la petición seguirá en el fondo, porque la “suscripción/observable” sigue ahí. Entonces, lo que se hace es que en el ngOnDestroy se desasignan las suscripciones. Cuando hacemos esto, normalmente lo hacemos a mano, es decir, tenemos que ir componente por componente y desuscribir todo… retirarlo, matarlo…
Pero ahí está el dilema, ¿por qué diablos hacer esto a mano una y otra y otra y otra vez? y es aquí donde hay algunas librerías o métodos que nos ayudan, por ejemplo:
https://www.npmjs.com/package/@ngneat/until-destroy
Esta librería nos permite quitar las suscripciones de forma automática en los servicios (hablando del ejemplo de HTTP) para que sea más fácil y así sea más genérico/global. De esa forma evitamos ese tipo de problemas al hacer código más manual, que forza a los desarrolladores a saber cómo se manejan las cosas cuando los servicios son “por endpoint” y por concluyente, siempre deberán estar creados por cada endpoint que se genera y así ya los desarrolladores no se preocupan por retirar esas suscripciones en cada componente que crean simplemente consumen los servicios como debería de ser. Claro está, que seguimos hablando de HTTP, si hay eventos en el DOM u otras acciones, sería diferente.
¿Qué otra cosa se debe evitar cuando se trabaja en Angular?, bueno, este es otro punto que noto que hacen muchos desarrolladores, que es que la vista ponen métodos que requieren de una función simple en la lógica de negocios. Por ejemplo:
// En la vista:
<un-componente (click)="funcion($evento)"></un-componente>
// En la lógica:
funcion(evento: any) {
this.variable = evento;
}En este caso, la asignación podría hacerse simple como:
<un-componente (click)="variable = evento"></un-componente>Y es que sobresaturamos la lógica con muchas reasignaciones que se pueden hacer al nivel de la vista.
Y además, recordemos un poco el proceso de Render:
Angular funciona como two-way data binding, lo que hace que esto sea posible:
Componente <-> Vista
¿Pero qué diablos es eso Asfo?, no me jodas… Bueno, básicamente es que la vista pueda actualizar una variable del componente, y que el componente pueda actualizar una variable a la vista. A diferencia de otros como React, React solo puede actualizar hacia un lado, es decir: La vista al componente, o el componente enviarle un valor a la vista y para lograr que se actualicen requieren de funciones intermediarias que actualicen el render.
En Angular, como se menciona, no es así, pero, esto viene con un truco, para que Angular pueda saber qué está pasando, tiene una detección hacia las variables, haciendo que “escuche” constantemente el valor de todas las variables, así que si nosotros creamos una variable en el componente, lo asignamos en la vista, entonces, ambos estarán vinculados, ambos estarán escuchando, así que la función en el caso superior estará siendo asignada, una y otra y otra vez, en los eventos y en la escucha con la variable, por lo que Angular requerirá ejecutar esa función (en realidad JS pero ustedes entienden) para después asignar y obtener el valor de la variable, cuando bien podríamos evitar que Angular requiera del componente para hacer esto.
Así que ya saben, menos funciones, más asignaciones sencillas en las vistas…
¿Y cuál es la última cosa que requerimos evitar?, bueno, también he notado que hacen muchísimas selecciones con ViewChild … básicamente esta es una manera de acceder a un componente y a sus métodos como si fuera un document.getElementById pero que el elemento HTML tenga funciones… es una manera en la que nos permite Angular poder asignar cosas, u obtener desde componentes internos para que podamos manipularlos de cierta forma (paréntesis, quien hizo esto se merece el cielo porque en ocasiones me ha sacado de problemas cuando el componente es muy “especial” pero tiene métodos que te salvan y solo así se pueden acceder, te estoy viendo a ti NgSelect).
Sin embargo, hay muchas veces que esto se hace de forma indiscriminada… haciendo que incluso haya selectores con clases y haciendo que entonces, cuando no se necesita, se accedan a elementos forzando accesos que pueden ser manipulados de otras maneras…
Recuerda, al final esto genera una conexión y abre el componente para que tengas las disponibilidades, haciendo que para el usuario final (¿o mejor dicho su PC?), sea más pesado manipular el UI y por lo tanto la web puede sentirse lenta, trabarse, requerir más potencia, etc… Así que piensa 2 veces antes de usar este tipo de funcionalidades.
Por ahora, esta es una lista de algunas cosas, en la próxima publicación hablaremos de por qué debes evitar usar UntypedForm y generar formularios con el FormBuilder y mejor permitir que sea HTML + [ngModel] quienes te apoyen en la generación de formularios.
Nos vemos en la próxima publicación.
