Ciclo de Vida de Componentes en Angular: Constructor a OnDestroy

Curso de Angular: Componentes y Servicios

Contenido del curso

Componentes

Servicios

Pipes y Directives

Best practices

Despedida

20
Componentes y Servicios en Aplicaciones Web
01:09 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0011:31

Ciclo de Vida de Componentes en Angular: Constructor a OnDestroy

Curso de Angular: Componentes y Servicios

Clase 6 de 20

Clase 6 / 20

Recursos

Comprender el ciclo de vida de los componentes en Angular es fundamental para saber en qué momento exacto ejecutar cada tipo de lógica. Cada componente y directiva pasa por una serie de etapas —desde su creación hasta su destrucción— y Angular expone hooks específicos que permiten intervenir en cada una de ellas. A continuación se desglosan estos eventos en el orden en que se ejecutan, con ejemplos prácticos basados en un ImageComponent.

¿Qué papel cumple el constructor en el ciclo de vida?

El constructor es lo primero que se ejecuta cuando Angular crea la instancia de un componente [0:28]. Su función es inicializar la clase, pero tiene restricciones importantes:

Se ejecuta una sola vez por cada instancia del componente.
Corre antes del render, es decir, antes de que el componente se pinte en el navegador.
No debe contener lógica asíncrona: ni peticiones fetch, ni suscripciones, ni promesas.
Solo deben realizarse asignaciones inmediatas, como establecer valores por defecto.

Por ejemplo, si necesitas asignar un valor a this.image, el constructor es un lugar válido porque la operación se resuelve de forma instantánea [1:30]. Si creamos múltiples instancias del componente, cada una ejecutará su propio constructor una única vez.

¿Cómo detectar cambios en los inputs con ngOnChanges?

El siguiente hook en ejecutarse es ngOnChanges [2:05]. Para utilizarlo, se implementa la interfaz OnChanges y su método correspondiente. Sus características son:

Corre antes del render y también durante la vida del componente.
Se dispara cada vez que un input cambia de valor desde el componente padre.
Es el lugar correcto para reaccionar a modificaciones en las propiedades de entrada.

Si en app.component se envía un valor de imagen al componente hijo y ese valor se actualiza, ngOnChanges recibirá la notificación con el nuevo dato [2:45]. Este comportamiento lo convierte en un hook que corre múltiples veces, a diferencia del constructor.

¿Por qué no usar ngOnInit para detectar cambios en inputs?

Un error muy común es intentar detectar cambios de inputs dentro de ngOnInit en lugar de ngOnChanges [4:15]. Aunque ambos corren antes del render, ngOnInit se ejecuta una sola vez. Si necesitas escuchar continuamente las actualizaciones de un input, la detección debe estar en ngOnChanges.

¿Cuándo usar ngOnInit, ngAfterViewInit y ngOnDestroy?

Después de ngOnChanges, Angular ejecuta tres hooks adicionales que cubren el resto del ciclo de vida.

¿Qué hace ngOnInit y por qué es ideal para llamadas asíncronas?

ngOnInit se ejecuta una sola vez, justo después de que Angular ha inicializado todos los inputs del componente [3:25]. A diferencia del constructor:

Aquí sí podemos ejecutar lógica asíncrona: llamadas a APIs, fetch, promesas.
El componente alista los datos obtenidos y luego los renderiza.
Es el lugar estándar para cargar información del servidor.

¿Para qué sirve ngAfterViewInit?

ngAfterViewInit corre después del render, cuando todos los elementos hijos del componente ya están pintados en el navegador [4:40]. Si el componente contiene imágenes, plantillas con ng-template u otros componentes hijos y necesitas manipularlos de forma programática, este es el momento adecuado. Este hook es especialmente relevante en directivas, que suelen ejecutar su lógica principal en esta etapa [5:25].

¿Qué ocurre con ngOnDestroy al eliminar un componente?

ngOnDestroy se dispara cuando el componente se elimina de la interfaz [5:50]. Un ejemplo clásico es el uso de ngIf: cuando la condición cambia a falso, el componente se remueve del DOM y su instancia deja de existir. Este hook permite:

Limpiar suscripciones activas.
Liberar recursos.
Ejecutar cualquier lógica de limpieza necesaria.

El orden completo verificado en consola es: constructor → ngOnChanges → ngOnInit → ngAfterViewInit [6:15]. Al modificar un input después del render inicial, solo ngOnChanges se vuelve a ejecutar, confirmando que es el único hook que permanece escuchando durante toda la vida del componente [6:40].

Si quieres profundizar en cómo ngOnDestroy se comporta en escenarios reales con condicionales y ruteo, es un tema que se aborda con ejemplos prácticos en la siguiente sesión. ¿Has tenido algún caso donde confundiste ngOnInit con ngOnChanges? Comparte tu experiencia.