Componentes y databinding en Angular: Guía avanzada | Parte #2

Breve historia del View Encapsulation

Si te fijas, antes de dividir nuestra app en componentes, cuando generábamos contenido añadiendo un blueprint, el texto de la card era de color azul. El párrafo "Add new servers or blueprints!" también era azul previamente. Esto sucedía porque el archivo CSS del AppComponent así lo especifica:

Pero ahora, al haber dividido en componentes nuestro código, el template del AppComponent no contiene ningún <p> al que aplicarle el color de su archivo CSS. Los <p> están ahora repartidos entre el ServerElementComponent y el ControlPanelComponent.

Teniendo en cuenta que CSS se aplica en cascada, sin importar en qué archivo CSS definamos una regla, en nuestro caso debería aplicarse a todas las etiquetas <p> de nuestra app, buscando cualquier <p> siguiendo un patrón de AppComponent  elementos del AppComponent como el <app-control-panel> elementos del <app-control-panel>  hasta finalmente llegar a un <p> dentro del <app-control-panel> y aplicar ese color azul. Pero esto no es lo que sucede. ¿Por qué? 

Porque Angular sobrescribe el comportamiento por defecto del navegador, encapsulando los estilos CSS y aplicándolos únicamente al componente al que pertenecen.

Es el mismo principio que aplica Angular a los archivos .ts y .html de un componente: por defecto, lo que declaremos en dichos archivos sólo puede ser accedido desde dentro del mismo componente, y si queremos acceder desde fuera, tendremos que implementar una lógica de comunicación entre componentes como la que hablábamos en la parte #1 de esta serie. 

Esto significa que, si quisiéramos colorear todos los <p> de color azul, deberíamos aplicar una regla de CSS en el archivo CSS de cada componente donde haya etiquetas <p>. Por ejemplo, podemos cortar esa regla de nuestro app.component.css y añadirla al archivo server-element.component.css, que es donde la queremos. Y ahora, cuando generamos contenido pulsando el botón "Add Server Blueprint", éste vuelve a ser azul.

Cuando Angular fuerza esta encapsulación de estilos (en inglés, styles encapsulation o view encapsulation), lo hace aplicando un atributo distinto por componente. Inspecciona tu app con las dev tools para comprobarlo: verás que, como por arte de magia, el párrafo que ahora recibe la clase que lo pinta de color azul también contiene esa extraña adición subrayada en amarillo, que no tiene que ser igual en tu caso que en el mío. 

Si inspeccionas todas las etiquetas HTML de ese componente, verás, que todas comparten ese atributo: _ngcontent-syk-c2 en mi caso.

Si inspeccionas el primer párrafo de nuestra app ("Add new Servers or blueprints!"), verás que Angular le ha añadido otro atributo distinto a _ngcontent-syk-c2, porque ese <p> está dentro de otro componente (al ControlPanel).

Y esta es la manera que tiene Angular de decir: "tú, <p>, perteneces a este componente X, porque he creado un atributo único para identificar ese componente. Así que cuando desde el archivo CSS del componente X se defina un estilo para un <p>, sólo lo aplicaré a los <p> que estén dentro de ese componente X".  

Angular fuerza el "view encapsulation" dando un mismo atributo a todos los elementos HTML de un componente.

Este comportamiento de Angular emula la tecnología del shadow DOM, que no es compatible con todos los navegadores, y que consiste precisamente en encapsular cada nodo de HTML, haciéndolos así independientes entre sí. Pero al no ser compatible con todos lo navegadores, Angular utiliza este otro enfoque de view encapsulation para conseguir el mismo resultado.