WR 5: La historia de los pequeños objetos y la web de componentes

¿Qué tienen que ver los pequeños objetos con toda la inmensidad de la web? Mucho y más aún desde que se pusieron en marcha los Web Components, que han extendido su uso en el universo HTML5 durante los últimos años.

¿No sabes que llevamos años usando Web Components y que su uso está generalizado? Quizás no haya sido exactamente la revolución prevista, pero ha aportado orden y claridad al mundo del frontend.

La maquetación, el UX, ya desde hace tiempo tiene sus propios conceptos de desarrollo. Y cambia y crece a un ritmo frenético.

Los WebComponents son una innovación que trae la especificación de HTML5 y que viene a intentar solucionar problemas comunes del HTML. Existen quintales de información sobre esto tanto en forma de tutoriales, artículos, herramientas, librerías…

Este episodio tiene el deseo pretencioso poner algo de orden en este mundo, espero que el que propongo te sea útil :)

Comentar antes de nada que no todos los navegadores los renderizan sin ayuda de polyfills, unas librerías de Javascript que completan al navegador. Este es el gráfico de soporte de navegadores para WebComponents:

Los Web Components tienen cuatro subelementos o “patas” en las que se apoyan:

Custom elements ¶

Con esto cualquiera puede crear su propia etiqueta de marcado HTML y convertir la maquetación en un sistema mucho más semántico.

Estos elementos tienen que ser de nombre compuesto, esto es, separados por un guión para distinguirse de los estándar de HTML que tienen una sola palabra (<p>, <div>…).

Al estar basados en el HTMLElement, pueden ser una extensión o de ese objeto o de otros. Así podremos crear custom elements basados en elementos ya creados por terceros o en las librerías que tenemos listadas más abajo.

Templates ¶

La etiqueta personalizada del Custom element no tendría ningún sentido sin una plantilla que la acompañara, que nos dijera cómo mostrar ese elemento. Por ejemplo en muchas ocasiones necesitamos renderizar un listado con varios resultados que tiene un marcado específico.

Desde el punto de vista que más conozco, el backend, estamos acostumbrados a generar ese HTML.
Pero es más lógico pensar que debe ser el frontend quien mejor tome esta decisión pues las plantillas nos dejan definir ese marcado en detalle. Además su sintaxis se parece mucho al de sistemas de plantillas que ya conoces como handlebars, twig…

Y recuerda que trabajamos sobre la template directamente con Javascript, haciendo este elemento interactivo. Todo esto lo tienes en la especificación con más detalle.

Shadow DOM ¶

Es quizás la pata más completa y compleja de explicar.

Piensa en el Shadow DOM como en una puerta donde, al otro lado, está lo desconocido. Lo que realmente solo le importa al navegador, lo que está detrás de tu template y de tu custom element.

Así puedes encapsular y todo queda en este Shadow DOM: el marcado HTML de tu Web Component así como sus estilos. Así es, las reglas de CSS solo afectarán a ese componente y estarán dentro de su ámbito.

Esto acota un problema general del marcado HTML: su universalidad. Todas las etiquetas son globales y una simple regla de CSS puede afectar a todos los <div> que tengas en una maqueta. Hemos creado toda una parafernalia de herramientas alrededor de este problema para intentar solucionarlo con selectores, herencias, criterios de orden, pero la solución propuesta con Web Components nos crea un contexto único donde podremos alterar desde fuera, pero solo si lo hacemos a propósito.

Aquí si te recomiendo leer con atención los ejemplos de la guía de Google al respecto en español.

HTML Imports ¶

El más fácil de explicar, y el que era ilógico que no existiera. Permite importar ficheros HTML desde otro fichero de esta extensión. Igual que hacemos desde hace siglos con imágenes, estilos, etc.

He recuperado este tema de los Web Components después de usarlo y disfrutarlo en un par de proyectos. Se me había olvidado que existían, lo reconozco. En uno de esos proyectos programamos con Ionic Framework para el desarrollo de una aplicación móvil híbrida y en el otro teníamos que solucionar unos encontronazos con la versión AMP de una web. Y resulta que ambos sistemas utilizan componentes.

Recursos de Web Components ¶

Veamos todos los recursos de los que hablamos en el podcast

• Episodio de Mentores en ZetaTesters
• Artículo sobre Web Components de Carlos Morales en octuweb, la base principal de este programa, muy recomendable,
• The broken promise of Web Component, un artículo en negativo sobre las promesas incumplidas por esta metodología.
• CanIUse, web donde podemos ver por navegadores que podemos usar o no.
• Documentación de Google sobre Web Components
• WebComponents, repositorio de componentes e información. En la portada podréis encontrar las compatibilidades por navegadores
• Polymer, librería de Google.
• X-tags, librería de Microsoft.
• Stencil, librería de los creadores de ionic que prometo probar en detalle.
• Material Components Web, otra librería de Google basada en Material Design.
• Component.io, convirtiendo el componente en producto.
• Express Web Components
• Gantry
• Mannequin
• Atomic Web Design
• Pancake CMS, un gestor basado en Web Components.

Cerramos el episodio con una pregunta de Alberto, en la que vemos cómo aligerar la carga de los vídeos incrustados de YouTube con un truco que nos manda él mismo, aquí tenéis el enlace al Light Youtube Embeds.

¿Te quedaste con dudas? ¿Sugerencias, correcciones…? Cuéntame cosas a través del formulario de contacto. Todo comentario es bienvenido.

Si te gustó el podcast distribúyelo y recomiéndalo donde quieras. Puedes seguirnos en twitter en @webreactiva y además seguir mis andanzas en mi canal de youtube.

Espero que este episodio te sea útil. ¡Hasta el próximo!