Ediciones ENI Editorial | líder en informática
Para llegar mas lejos
Introducción
En este capítulo, vamos a abordar determinadas nociones importantes que no se han mencionado hasta ahora. Sin embargo, se trata de nociones avanzadas que siempre es importante conocer.
En inglés, el renderizado en el lado del servidor se llama Server Side Rendering. Su acrónimo SSR aparece muy habitualmente cuando se habla del tema.
Renderizado en el lado del servidor
Cuando se carga una aplicación Angular tradicional, el navegador empieza descargando el archivo HTML principal de la aplicación (generalmente el archivo index.html en la raíz del proyecto). Siguen todos los assets referenciados dentro de este archivo (JavaScript, CSS, imágenes, etc.). A continuación, el JavaScript se interpreta y después se ejecuta. En esta fase de ejecución, se carga el framework Angular. Una vez que pasa esta etapa, Angular carga los componentes a visualizar, donde el binding se realiza antes de mostrar por fin la página.
La fase de interpretación y ejecución de JavaScript puede ser más o menos larga, en función de la potencia de la máquina que carga la página. En caso de un teléfono móvil, estos tiempos pueden ser bastante elevados.
Además, los crawlers de los motores de búsqueda no siempre ejecutan el JavaScript y por lo tanto, se encuentran analizando una página en blanco cuando visitan nuestra aplicación.
El renderizado en el lado del servidor permite devolver una página HTML al navegador previamente renderizada. Por lo tanto, los crawlers de los motores de búsqueda pueden interpretar el contenido de esta, incluso sin ejecutar JavaScript. Además, esto permite al navegador mostrar la página tan pronto como se descarga el archivo HTML que le devuelve y por lo tanto, antes de cualquier fase de interpretación y ejecución del JavaScript.
Por lo tanto, gracias al renderizado en el lado del servidor, es posible visualizar la página más rápidamente. Sin embargo, solo se vuelve interactiva cuando el JavaScript es interpretado por el navegador y Angular ha cargado la aplicación.
1. Principio de la implementación
El principio del renderizado en el lado del servidor es tener un servidor Node.js (u otro como ASP.NET Core por ejemplo), que utiliza la misma aplicación Angular que el cliente.
El servidor va a utilizar esta aplicación para generar el HTML en función de los argumentos que se pasan a la consulta HTTP.
Sin embargo, el módulo Angular que debe ejecutar el servidor no puede ser el mismo que el utilizado por el cliente. De hecho, el módulo utilizado por el cliente se refiere a los módulos de Angular que requieren ejecución dentro de un navegador...
La detección de cambios
1. ¿Por qué la detección de cambios?
Una aplicación se basa en un conjunto de modelos. El objetivo es presentar estos modelos de una forma u otra como una interfaz para el usuario. En el caso de una aplicación Angular, la interfaz es el DOM y, por lo tanto, el modelo se convierte en un conjunto de elementos DOM: bloques, listas, elementos HTML 5, etc.
La visualización de esta interfaz es relativamente simple. Por un lado, hay una entrada, el modelo de aplicación, puede ser en forma de objetos, tablas o referencias de objetos. Por otro lado, hay una salida, el DOM. Entonces, si nos atenemos a la renderización básica, un método de renderización simple sería suficiente.
Sin embargo, el modelo cambia y la aplicación debe realizar un seguimiento de los cambios en el modelo, para poder reajustar el DOM en consecuencia para el usuario. Esto debe hacerse rápidamente para proporcionarle al usuario una experiencia fluida e intuitiva.
Entonces, cuando el modelo cambia, la aplicación tiene que acceder al DOM y es costoso. En realidad, el objetivo es minimizar el acceso al DOM tanto como sea posible.
Para proyectar los datos en la interfaz de usuario y actualizarlos de forma dinámica y efectiva, primero debe identificar las fuentes que pueden causar cambios. Son tres: eventos, XHR y temporizadores (timers).
Los eventos
Los eventos que se generan desde el DOM, como los clics o incluso la validación de formularios, activan la detección de cambios. A continuación, aquí hay un ejemplo con un componente que muestra una entidad framework.
interface Framework {
name: string;
version: number;
} Por lo tanto, el componente tiene una propiedad framework que se inicializa en el constructor. Un método upgrade actualiza la versión del framework, y este método se lanza cuando el usuario pulsa el botón disponible.
@Component({
selector: 'app-root'
template: `
<pre>{{framework | json}}</pre>
<button (click)="upgrade()">Upgrade !</button>
`
})
export class AppComponent { ...El ciclo de vida de un componente
Durante el desarrollo de una aplicación Angular, es importante ser consciente del ciclo de vida de esta aplicación. Como la aplicación está formada por componentes, esto pasa principalmente por el ciclo de vida de los componentes per se.
Angular gestiona el ciclo de vida de un componente y por lo tanto, es Angular quién se ocupa de crear el componente, y después entregarlo con sus propiedades, y para terminar, destruirlo cuando sea necesario.
Angular proporciona hooks sobre los que se puede apoyar el desarrollador para interactuar con el ciclo de vida de un componente. El término exacto es lifecycle hooks.
1. Presentación de los lifecycle hooks
a. Los diferentes hooks
Los lifecycle hooks están disponibles en los componentes, así como en las directivas, los componentes tienen algunos hooks específicos que las directivas no tienen.
Los lifecycle hooks son los siguientes:
-
ngOnChanges: Se llama cuando un input se define o se modifica. El método proporciona un argumento con los valores antes y después de la modificación de los inputs implicados.
-
ngOnInit: Se llama una única vez después del primer ngOnChanges. Permite inicializar el componente o la directiva después de que se hagan los primeros bindings, los inputs se cargan en el componente en este momento.
-
ngDoCheck: Se llama después de cada detección de cambios. Permite detectar los cambios que Angular no detecta él mismo.
-
ngAfterContentInit: Se llama después de que el contenido externo se haya proyectado en el componente (principalmente con la transclusión).
-
ngAfterContentChecked: Se llama como consecuencia de la verificación del contenido externo, proyectado en el componente.
-
ngAfterViewInit: Se llama cuando las vistas del componente y de sus hijos se inicializan.
-
ngAfterViewChecked: Se llama después de cada verificación de las vistas del componente y las de sus hijos.
-
ngOnDestroy: Se llama justo antes de que Angular destruya el componente o la directiva.
Los métodos ngAfterContentInit, ngAfterContentChecked, ngAfterViewInit y ngAfterViewChecked son exclusivos de los componentes. El resto están disponibles para los componentes, así como para las directivas.
b. Utilizar un lifecycle hook
La utilización de los lifecycle hooks se hace importando @angular/core, las diferentes interfaces...