polymer: 11. en producción

Cómo manejar polymer en producción

Vincent Van Gogh

archivado en: JavaScript / 29 marzo, 2016 / taller:

Ahora que ya sabemos cómo preparar un componente con polymer, nos falta ver cómo encajarlo en un entorno real de trabajo y, en este sentido, lo primero es destacar que los componentes funcionan en cualquier escenario normal del desarrollo web. Es decir, podemos utilizarlos en páginas normales, en páginas php o jsp, con wordpress, con plantillas tipo handlebars, con un framework para hacer singles pages applications como angular, etcétera.

Ya he explicado cómo combinar angular con polymer mediante listeners, lo cual es aplicable a cualquier otro frame, por lo que no me repetiré aquí. En cambio, sí quiero destacar que podemos usar cualquier librería o similar dentro de un componente. Por ejemplo, si necesitamos utilizar en un componente moment.js, muy útil para trabajar con fechas en javaScript, la jugada sería tan sencilla como wrapear la librería en un archivo html.

moment.html

<script src='moment.min.js'></script>

y luego importarlo en el componente.

<link rel="import" href="../../bower_components/moment/min/moment.html">

<dom-module id="foo-component">

<template>

Ahora es {{now}}

</template>

<script>

Polymer({

is: "foo-component",

properties: {

now: String

},

ready: function() {

this.now = moment().format();

}

});

</script>

</dom-module>

Frente a esta estrategia, alguien podría argumentar que entre componentes y librerías, la organización y carga de archivos comienza a ser un lío, pero para eso tenemos otra herramienta formidable: vulcanize ^^

Vulcanize

A l a que tengamos un par de componentes, para organizar los archivos lo mejor es situarlos todos en una carpeta que podemos llamar components y ahí incluir un archivo components.html que enlazamos desde el index, en el cual vamos importando los componentes.

index,html

<script src="bower_components/webcomponentsjs/webcomponents-lite.min.js"></script>

<link rel="import" href="bower_components/polymer/polymer.html">

<link rel="import" href="components/components.html">

/components

components.html

<link rel="import" href="foo/foo.html">

<link rel="import" href="bar/bar.html">

/foo

foo.html

/bar

bar.html

El siguiente paso es pasarlos por vulcanize, una herramienta que sirve para compactar todos los archivos. La instalamos:

npm install vulcanize --save-dev

Y luego le indicamos el nombre del archivo final, el que contendrá todos los componentes compactados, y a partir de dónde debe empezar a buscar.

vulcanize -o build.html components/components.html

gulp vulcanize

Aunque podemos ejecutar vulcanize directamente, es más cómodo tirar de gulp, ya que nos permite precisar algunos parámetros: borrar comentarios, compactar el js y compactar las css. El mecanismo es bien sencillo:

1. Instalamos el módulo:

npm install --save-dev gulp-vulcanize

2. Y configuramos la tarea.

const gulp = require('gulp');

const vulcanize = require('gulp-vulcanize');

const vulcanizeOptions = {

stripComments: true,

inlineScripts: true,

inlineCss: true

};

gulp.task('vulcanize', () => {

return gulp.src('./components/components.html')

.pipe(vulcanize(vulcanizeOptions))

.pipe(gulp.dest('dist/components'));

});

gulp.task('default', ['vulcanize']);

De todas maneras, hay ocasiones en las que no nos conviene juntar todos los componentes en un solo archivo, sino distribuirlos en varios en función de las interdependencias, como ocurre en las grandes aplicaciones, donde conviene montar un sistema de carga bajo demanda (lazy load). El dilema en general es el siguiente: hasta que no se ponga en marcha la versión 2 del protocolo http, cada viaje al servidor, cada petición, tiene un coste considerable en milisegundos (unos 200). Es decir, cuántas más cosas pida el cliente, más se tardará en cargar la página, aunque sean muy ligeras. Sin embargo, el que se deba cargar un archivo muy pesado al principio para que se empiecen a ver las cosas, tampoco parece muy saludable.

Un google developer llamado Paul, desconozco su apellido, explica bien cómo organizar un sistema lazy load con polymer, por lo que no trataré el tema aquí, pero quiero insistir en que no debemos ser dogmáticos. Ni siempre hay que compactar los componentes, ni siempre debemos manejarlos tal cual. Cada escenario es distinto y plantea sus propias necesidades. No es lo mismo usar los componentes integrados con algún frame, que en una página normal, que en una aplicación híbrida o que en la arquitectura que propone el propio equipo de polymer, el llamado polymer starter kit. Vamos a conocerla, pero antes de entrar en materia,tenemos que echarle un vistazo al catálogo de elementos de polymer.

La tabla periódica de polymer

Como decía al principio de esta serie, polymer está formado por tres cosas: un pollyfil para los navegadores que no soportan características de los web componentes, la librería para trabajar de forma más cómoda y eficaz los componentes y un catálogo de componentes que han desarrollado en google. Los elementos de este catálogo se agrupan según su funcionalidad en:

1. Iron elements: aquí incluyen los componentes que más o menos forman parte del core de una aplicación estándar, tanto en sus gadget visuales -colapsables, piezas de un formulario, layouts, etcétera-, como los que suelen sustentar el back del front xD, como las llamadas ajax, la documentación o los tests.

2. Paper elements: son elementos basados en las propuestas del llamado google material design, un lenguaje visual que afecta a los estilos y los elementos de una web. En cierta manera, serían el equivalente junto a parte de los iron del bootstrap de twitter.

3. Google web components: como se deduce del nombre, sirven para trabajar con los componentes webs de google, tal que el google-maps, el  google analitycs, el calendar, youtube, etcétera.

4. Gold elements: lo cierto es que no le veo yo mucha utilidad a este grupo. En teoría reúne los elementos necesarios para el comercio electrónico, pero en la práctica se reduce a unos pocos inputs habituales en los formularios de pago, como el correo o el cvc y se echa en falta utilidades más serias como el pago por paypal. Quizás los incorporen en un futuro, aunque por algún lado leí que más o menos han cerrado el catálogo.

5. Neon elements: este grupo, dedicado a las animaciones, solo tiene un componente que funciona combinado con los irons.

6. Platinum elements: aquí se agrupan componentes pensados para las progresive web apps, como la mensajería push o los service workers. Mola.

7. Molecules: el nombre de este grupo recuerda al atomic design y engloba dos componentes que muestran cómo combinar componentes con librerías de terceros, una para mostrar código y otra para picar marked. Su utilidad es básicamente pedagógica.

Visto esto, vamos ya sí con la propuesta arquitectónica de polymer.

El polymer starter kit

Este pack de google consiste en esencia en un workflow de tareas gulp y una propuesta para articular web componentes en una single page application a partir un ruteador. Para instalarlo, se baja el zip (la versión completa), se descomprime, ejecutamos npm install, bower install y ale op, todo listo para empezar un proyecto.

Las task de gulp no tienen mucho misterio, son el pack habitual más el vulcanize y alguna que otra más extravagante, como deploy-gh-pages para preparar una gh-page de git, por lo que pasaré por encima.

Si alguien aún no ha manejado gulp, le recomiendo el artículo Gulp for Beginners de Zell Liew.

Y sobre la arquitectura, la verdad, es que tampoco tengo mucho que decir, salvo que no me convence :P. En esencia consiste en ir incluyendo componentes dentro de componentes hasta completar la aplicación, que es en sí misma un componente. Es una propuesta trasgresora que rompe con el paradigma mcv y que puede funcionar en una aplicación muy pequeña, de apenas un par de pantallas. Pero no veo nada claro que pueda funcionar en una aplicación mediana o grande y menos en un entorno real de trabajo, donde hay perfiles más enfocados a la maquetación y otros a la programación.

Esto no quiere decir, ni por asomo, que no me guste polymer, una herramienta que cuanto más uso, más me gusta, sino que no creo que sirva para armar los cimientos de una aplicación web. De hecho, creo que va incluso contra la propia filosofía del proyecto. Sería, para el caso, como haber usado en su día un plugin de jquery para desarrollar toda una web. Cada frame, cada librería, tiene su utilidad y para la estructura hay herramientas más útiles, como angular o meteor.

Bueno, pues a falta de hablar de tests y polymer, un tema que tardaré en tratar, que tengo varios más en cola. Con lo expuesto hasta aquí espero que este taller sirva como introducción al proyecto.

|| Tags:

valoración de los lectores sobre polymer: 11. en producción

  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • 5 sobre 5 (1 votos)

¿Te ha parecido útil o interesante esta entrada?
dormido, valoración 1 nadapensativo, valoración 2 un poco sonrisa, valoración 3 a medias guiño, valoración 4 bastante aplauso, valoración 5 mucho

Tú opinión es muy importante, gracias por compartirla!

2 respuestas a “polymer: 11. en producción

  1. Rafa García el dijo:

    Funciona perfectamente en proyectos de gran tamaño y entornos reales de trabajo y grandes empresas y organizaciones de España están apostando decididamente por el.

    Saludos.

Aportar un comentario


*