Contexto para ejecución de Polymer 3

  • Por
Qué necesitamos para integrar Polymer 3 en sitios y aplicaciones web, reconociendo los scripts principales para funcionar.

En este artículo queremos dar una descripción del contexto necesario para poder usar Polymer en sitios y aplicaciones web. Es decir, qué necesitamos para que Polymer 3 se pueda poner en producción en cualquier aplicación frontend o sitio web tradicional.

Con el lanzamiento de Polymer 3 hemos dado la bienvenida a diversos cambios importantes en la librería. El primero el uso de npm como gestor de dependencias y segundo y más importante, el uso de los import de ES6 en lugar de los HTML imports. Todo esto no es nuevo si estás leyendo el Manual de Polymer 3, pues ya hablamos bastante de estos cambios en el artículo de Introducción a Polymer 3. La novedad en este artículo será identificar y describir las partes necesarias para que nuestros componentes de Polymer puedan funcionar tanto en sitios web como aplicaciones web y por supuesto, PWA.

Aunque pueda parecer un poco tostón dedicarnos a teorizar un tanto sobre los ingredientes necesarios para poner a Polymer en funcionamiento, nos va a venir muy bien este conocimiento para poder integrar Polymer 3, y Web Components en general, en cualquier tipo de proyecto. Y es que recordemos que Polymer se promueve a sí mismo como una librería que sirve de complemento para cualquier tipo de proyecto web y no un reemplazo de otras que podamos estar usando actualmente. Gracias a las novedades de Web Components y Polymer 3, esta filosofía es una realidad. Pero para ser capaces de ponerla en práctica es importante detenernos a explicar antes el contexto necesario para que Polymer pueda funcionar en cualquier tipo de proyecto.

Más allá del Polymer Starter Kit y PWA Starter Kit

Primero hay que hacer una mención especial a estos proyectos, que tienen todo lo necesario para construir aplicaciones con Polymer 3. Pero ojo al detalle con la palabra "aplicaciones". Son proyectos para construir lo que se conocen como Progressive Web Apps, pero si quieres usar Polymer en otros contextos diferentes tendrás que aprender más detalladamente el contexto de ejecución de Polymer 3, para poder reproducirlo en tus propios proyectos. De este modo tendrás las claves para integrar Polymer 3 modificando tu flujo de desarrollo actual, o crear tu propio entorno de desarrollo para tu stack de tecnologías preferido.

Nota: En cualquier caso, conviene tener muy cerca Polymer Starter Kit y PWA Starter Kit, ya que nos pueden dar unas pistas muy buenas sobre cómo organizar nuestras aplicaciones o sitios web donde usar Polymer 3. Hay mucho que aprender de ellos.

Existen muchos motivos por los que no siempre podremos basarnos en los mencionados Polymer Starter Kit y PWA Starter Kit, por ejemplo:

  • Necesitar manejar una estructura de proyecto distinta.
  • Usar Polymer en el contexto de aplicaciones basadas en React, Angular, Vue, etc.
  • Usar Polymer un sitio web tradicional (como los que se construyen con WordPress, por ejemplo).

En resumen, para ampliar el rango de proyectos donde usar Polymer, no podrás siempre basarte en el Polymer Starter Kit o el PWA Starter Kit. Tendrás que buscarte la vida por tus propios medios y crear o integrar Polymer en un flujo de trabajo personalizado.

Para ello una herramienta fundamental es Webpack, un empaquetador de archivos Javascript que es usado en conjunto con muchas otras tecnologías frontend. Webpack nos dará todas las utilidades para que poner Polymer 3 en funcionamiento sea algo sencillo, rápido y viable en cualquier situación. Aunque en este artículo no vamos a hablar todavía de Webpack en particular, el objetivo final de este texto es sentar las bases de conocimiento que necesitas poseer sobre Polymer, para que puedas entender cómo crear tu propio flujo con Webpack, o personalizar el existente. Pero tranquilo, en futuros artículos entraremos más en detalle con Webpack, ahora permíteme algo de teoría (espero no aburrirte mucho).

Piezas para que Polymer 3 funcione en cualquier proyecto frontend

Ahora vamos a describir, punto por punto, todo el conjunto de archivos necesarios para que Polymer funcione.

Polyfill de WebComponents

Este es el conjunto de librerías para que la tecnología de WebComponents funcione en cualquier navegador. WebComponents está disponible ya de manera nativa en muchos navegadores, pero algunos todavía tienen carencias en su compatibilidad. En muchos casos se solucionarán en un breve espacio de tiempo, pero en algunos casos, como Internet Explorer siempre vamos a necesitar del Polyfill.

El polyfill de los Webcomponents está en https://github.com/WebComponents/webcomponentsjs y allí encontrarás una buena fuente de información sobre cómo funciona y cómo ponerlo en marcha.

Lo interesante de este polyfill es que está construido para que se cargue de manera "modular". Es decir, cada navegador cargará las partes del estándar de WebComponents que no soporta en la actualidad. Gracias a esto, el código del Polyfill está muy optimizado, porque solo se descarga y se ejecuta lo que realmente necesita el cliente web que se está usando.

Una vez instalado el Polyfll con npm, que puedes hacer con el comando "npm install @webcomponents/webcomponentsjs", para que se carguen los módulos necesarios en el navegador, tenemos que incluir el script "webcomponents-loader.js". Lo haremos con algo como esto:

<script src="node_modules/@webcomponents/webcomponentsjs/webcomponents-loader.js"></script>

Script custom-elements-es5-adapter.js

Hay un script llamado custom-elements-es5-adapter.js, que está incluido en el polyfill de los WebComponents, sobre el que debemos de detenernos. Este script no es absolutamente necesario cargarlo, sino más bien opcional. Necesitarlo o no dependerá de si transpilas o no a ES5 el código de los componentes.

El script custom-elements-es5-adapter.js sirve para que el código de registro de componentes (custom elements) funcione en su versión ES5. Es decir, si transpilas el código ES6 a ES5 y entregas a navegadores que tienen soporte con el estándar Web Components V1 código escrito con ES5, necesitarás este script para que todo te funcione.

La explicación de esta necesidad es que, para navegadores compatibles con el estándar de Custom Elements, sólo es posible hacer el registro de componentes a través de clases ES6. Si has transpilado el código a ES5 ya no tienes clases ES6, por lo que no puedes registrar custom elements a no ser que cargues previamente custom-elements-es5-adapter.js.

Quizás pueda resultar un poco lioso, así que voy a dar todas las alternativas.

  • Para navegadores antiguos que no soportan ES6 (por ejemplo IE 11): Debe proporcionarse siempre código transpilado a ES5. Para estos navegadores no hace falta cargar custom-elements-es5-adapter.js.
  • Para navegadores modernos que soportan ES6 pero que no soportan todavía el estándar Web Components V1 (Por ejemplo, Firefox en el momento de escribir este artículo): Se puede entregar código transpilado o no transpilado. Es indiferente, pero tendrá más rendimiento si no se transpila.
  • Para navegadores modernos que soportan ES6 y además soportan el estándar Custom Elements de Web Components V1 (Chrome, Safari): Lo ideal es entregar código no transpilado, pero en el caso que se les entregue código transpilado, debe ser cargado antes el mencionado script custom-elements-es5-adapter.js. Esto es debido a que el estándar de Web Components V1 tiene como restricción usar clases ES6 originales (sin transpilar).

Esa carga condicional del mencionado script se podría realizar mediante este código:

<script>if (!window.customElements) { document.write('<!--'); }</script>
<script src="js/webcomponentsjs/custom-elements-es5-adapter.js"></script>
<!--! no quites este comentario!!! -->

El código anterior hace que el script custom-elements-es5-adapter.js solamente se cargue para navegadores que sí soportan el estándar CustomElements. Pero insisto que este script no sería necesario cargarlo si distribuimos el código con ES6.

Transpilado o no transpilado

Si tienes que decidir entre entregar el código transpilado o no, es siempre positivo no transpilar si el navegador es compatible con ES6 (ES2015). Ese asunto lo he explicado ya en el artículo Distribuir Javascript transpilado o no (ES5 o ES6) por lo que no voy a repetirme.

En el caso de WebComponents V1, como forzosamente los componentes (custom elements) tienen que escribirse con ES6, lo mejor es no transpilar. Primero por el aumento de rendimiento y segundo porque así nos ahorramos cargar el custom-elements-es5-adapter.js.

Los navegadores que no entienden ES6 (aparte de las clases de Programación orientada a objetos son necesarios los ES6 imports) tendremos que entregarles a ellos el código transpilado.

Para poder entregar a cada navegador el código que se debe (transpilado o no transpilado), podemos generar dos opciones del código de los componentes y cargarlas con el uso de type="module" y nomodule. Esta técnica está explicada con detalle en el artículo de ES6 Modules y nos producirá un código como este:

<script src="js/componentes-en-es6.js" type="module"></script>
<script src="js/componentes-en-es5.js" nomodule></script>

Conclusión

Eso es todo lo que necesitas saber de teoría para poder integrar componentes creados con Polymer 3 en cualquier tipo de proyecto, ya sean sitios web, aplicaciones web o las novedosas PWA.

Seguramente querrás aprender ahora cómo instalar y montar todas estas dependencias, así como producir los archivos necesarios para que los componentes se puedan usar en tus proyectos. Para ello usaremos Webpack, que nos permite crear un flujo de desarrollo completamente personalizado, aunque será materia para el siguiente artículo.

Autor

Miguel Angel Alvarez

Miguel es fundador de DesarrolloWeb.com y la plataforma de formación online EscuelaIT. Comenzó en el mundo del desarrollo web en el año 1997, transformando su hobby en su trabajo.

Compartir