WebComponents: un vistazo rápido

Acercamiento al mundo de los WebComponents, qué son y cómo funcionan, por qué deberíamos empezar a usarlos, y si ya están listos para emplearlos en producción.

Índice de contenidos

• 1. ¿Por qué deberíamos usar WebComponents?
• 2. ¿Qué son y cómo funcionan los WebComponents?
• 3. WebComponents en producción
• 4. Enlaces y referencias

1. ¿Por qué deberíamos usar WebComponents?

Hasta que aparecieron los WebComponents las páginas webs definían su paleta de componentes que seguían la guía de estilo corporativa, definiendo por un lado su estructura HTML, por otro funciones JavaScript, y por otro estilos que les otorgaban el look and feel que permitía que se integraran visualmente en la web con coherencia.

Pensemos así, en, por ejemplo la página web de reserva de hoteles, donde tiene componentes propios para su negocio, como por ejemplo, un rango de fechas: desde – hasta. O un banco, donde tiene campos de CCC, IBAN o un campo compuesto por número de tarjeta de crédito, títular, y fecha de caducidad. Son susceptibles de convertirse en componentes.

Que bien nos vendrían los siguientes componentes:

<date-range>
<input-iban>
<input-credit-card type="visa">

Pues para eso están los WebComponents.

Y aquí es donde choca con las modas. Ahora está muy de moda usar frameworks MVC en el lado del cliente, y muchos de ellos tienen resuelto el problema de cómo crear componentes. El problema es que los componentes creados así, se casan con la tecnología. Y los componentes creados con AngularJS en su versión 1, pues dependen de que la web esté usando esta versión. Por tanto, yo prefiero utilizar estos frameworks MVC para orquestar todo lo demás, pero utilizando WebComponents estándar, que sé que me van a funcionar independientemente del framework de turno utilizado. Me van a funcionar, incluso en páginas web clásicas, que no son «Single Page Applications».

En este sentido, ¿no es mejor para cualquier empresa tener su propia paleta de componentes definidos de forma estándar con WebComponents?

Yo sólo le puedo ver ventajas.

[teaser img=»https://www.adictosaltrabajo.com/wp-content/uploads/2016/08/laboratorio-tecnologias-front.jpg»]
Vivimos un momento de espectacular florecimiento de diversas tecnologías front, dando lugar a un ecosistema muy volátil y cambiante, dirigido en muchos casos por las modas, y éstas nunca deben imponerse al sentido común. Los WebComponents son un estándar que desacopla su uso de la tecnología empleada para construirlos.
[/teaser]

2. ¿Qué son y cómo funcionan los WebComponents?

Son cuatro los mecanismos nuevos que se juntan para llevar esta revolución al HTML. Por un lado, tenemos nuevos elementos HTML personalizados, llamados Custom Elements y que nos permitirán definir nuevas etiquetas HTML a nuestro antojo. Por otro lado, disponemos de la definición de plantillas, templates que vamos a usar para definir cómo serán internamente esos elementos en base a otras piezas más pequeñas, otros elementos HTML previos, o elementos personalizados, pudiendo de esta forma, hacer plantillas complejas. Otra funcionalidad de que disponemos es el Shadow DOM que es como el DOM interno del elemento que estamos creando, y que está oculto para ser manipulado desde fuera. Esto es genial, porque los CSSs de fuera del componente no sobrescribirán los estilos que definamos dentro del mismo, al estar esté DOM oculto al resto de la página. Y luego la cuarta funcionalidad, los HTML imports, que se invocan en la cabecera para realizar la carga del WebComponent, y que esté disponible en nuestra página para poder hacer uso del elemento personalizado.

Así que todo se resume a la combinación de estas cuatro definiciones:

• Custom elements
• HTML Templates
• Shadow DOM
• HTML Imports

Los HTML Templates ya están incluidos dentro de la especificación de HTML5, mientras que los demás, su especificación está en modo borrador por el W3C. Pero se espera que no sufran ya demasiadas modificaciones. De hecho, la mayoría de los navegadores aceptan como un estándar de facto la especificación actual, con algunos matices.

Como pasa casi siempre, menos con JavaScript, los navegadores van por delante de la definición del estándar.

Pero esos matices, nos obligan en algunos navegadores, sobre todo en los más antiguos, a usar polyfills. Esto es, una serie de complementos en forma de código, para que los navegadores que no soportan el estándar de forma nativa, con estos complementos, sí puedan. Y aquí es donde aparecen frameworks de desarrollo de WebComponentes como X-Tag, Polymer, Bosonic y SkateJS. El más famoso de todos es Polymer, que detrás tiene a Google y una gran comunidad de desarrolladores. X-Tag no se queda atrás, ya que es Mozilla quien lo soporta.

3. WebComponents en producción

La primera pregunta que se hará alguien que se esté planteando usar WebComponents es: «¿y esto puedo usarlo en entornos productivos sin problema?». Lo cierto es que sí. Ya lleva bastante tiempo funcionando y son multitud de webs las que incorporan en su código Componentes Web. Hay catálogos de componentes listos para ser usados: y podemos encontrar desde Data Grids avanzados a mapas de geoposicionamiento, o gráficos estadísticos. Todo al alcance de una simple etiqueta personalizada.

Con esta versatilidad, ¿qué compañía no preferiría tener su propio juego de componentes? Donde cada componente define su propio aspecto, su comportamiento, y sus validaciones. Listo para ser utilizado, y que los desarrolladores sólo tengan que usar la etiqueta personalizada, sin preocuparse de efectos laterales e indeseados.

En un siguiente artículo, reseñaré como crear un componente web de ejemplo.

Enlaces y referencias

• Web Components (W3C)
  https://www.w3.org/standards/techs/components#w3c_all
• Web donde se unifica todo lo relativo a WebComponents
  http://webcomponents.org/
• Polymer
  https://www.polymer-project.org/1.0/
• X-Tag
  http://x-tag.github.io/
• Catálogo de WebComponents listos para ser usados
  https://customelements.io/