Plantillas del lado del cliente

 

 

 


Índice
  1. ¿Por qué lo usarías?
  2. Primeras impresiones
  3. Motor de plantillas
  4. Un ejemplo de bigote
  5. Organizar plantillas
    1. Escenario 1: Etiquetas de script
    2. Escenario 2: plantillas precompiladas
    3. Escenario 3: AMD y RequireJS
    4. Ver plantillas
  6. Consideraciones de rendimiento
  7. Conclusión
    1. Otras lecturas

Aunque las plantillas se pueden utilizar para generar cualquier tipo de texto, en este artículo proporcionamos ejemplos que utilizan HTML, ya que eso es lo que queremos en el desarrollo del lado del cliente. ¡Echemos un nuevo vistazo a las plantillas del lado del cliente!

 

El uso de plantillas en el navegador está cada vez más extendido. Mover la lógica de la aplicación del servidor al cliente y el uso cada vez mayor de plantillas inspiradas en patrones similares a MVC (modelo-vista-controlador) para adoptar el navegador. Esto solía ser un asunto sólo del lado del servidor, pero las plantillas en realidad también son muy poderosas y expresivas en el desarrollo del lado del cliente.

Crédito de la imagen: Viktor Hertz

¿Por qué lo usarías?

En general, aprovechar las plantillas es una excelente manera de separar el marcado y la lógica en las vistas y maximizar la reutilización y el mantenimiento del código. Con una sintaxis cercana al resultado deseado (es decir, HTML), tiene una manera clara y rápida de hacer las cosas. Aunque las plantillas se pueden utilizar para generar cualquier tipo de texto, en este artículo proporcionamos ejemplos que utilizan HTML, ya que eso es lo que queremos en el desarrollo del lado del cliente.

 

En las aplicaciones dinámicas actuales, el cliente necesita actualizar con frecuencia la interfaz de usuario (UI). Esto podría hacerse obteniendo un fragmento HTML del servidor que pueda insertarse fácilmente en el documento. Sin embargo, esto requiere que el servidor admita la entrega de dichos fragmentos (en lugar de páginas completas). Además, como desarrollador del lado del cliente responsable del marcado, desea tener control total sobre sus plantillas . No es necesario saber nada sobre Smarty, Velocity, ASP, alguna otra sintaxis oscura del lado del servidor o incluso peor: lidiar con código espagueti como HTML que contiene esas etiquetas infames ?o %por todas partes.

Así que echemos un nuevo vistazo a una alternativa viable: las plantillas del lado del cliente.

Primeras impresiones

Para empezar, me gustaría dar una definición del término "plantilla". Aquí hay una buena definición de foldoc:

"Un documento que contiene parámetros, identificados mediante una sintaxis especial, que el sistema de procesamiento de plantillas reemplaza por argumentos reales".

Observemos un ejemplo y veamos cómo se vería una plantilla básica:

h1{{title}}/h1ul {{#names}} li{{name}}/li {{/names}}/ul

Probablemente esto le resulte bastante familiar si conoce HTML. Contiene etiquetas HTML con algunos marcadores de posición. Los reemplazaremos con algunos datos reales. Por ejemplo con este objeto simple:

var data = { "title": "Story", "names": [ {"name": "Tarzan"}, {"name": "Jane"} ]}

La combinación de la plantilla y los datos debería dar como resultado el siguiente HTML:

h1Story/h1ul liTarzan/li liJane/ul/ul

Con la plantilla y los datos separados, resulta fácil mantener el HTML. Por ejemplo, cambiar etiquetas o agregar clases solo necesitará cambios en la plantilla. Además, agregar un atributo a elementos repetidos como el

  • El elemento solo debe realizarse una vez.

    Motor de plantillas

    La sintaxis de la plantilla (es decir, el formato de los marcadores de posición como {{title}}) depende del motor de plantilla que desee utilizar. Este motor se encarga de analizar las plantillas y reemplazar los marcadores de posición (variables, funciones, bucles, etc.) con los datos reales que se proporcionan.

    Algunos motores de plantillas no tienen lógica . Esto no significa que solo pueda tener marcadores de posición simples en una plantilla, sino que las funciones están bastante limitadas a algunas etiquetas inteligentes (es decir, iteración de matrices, representación condicional, etc.). Otros motores tienen más funciones y son más extensibles. Sin entrar en detalles aquí, una pregunta que debe hacerse es si permite y cuánta lógica permite en sus plantillas.

    Aunque cada motor de plantillas tiene su propia API, normalmente encontrarás métodos como render()y compile(). El proceso de renderizado es la creación del resultado final colocando los datos reales en la plantilla. En otras palabras, los marcadores de posición se reemplazan con los datos reales. Y si hay alguna lógica de plantilla, se ejecuta. Compilar una plantilla significa analizarla y traducirla a una función de JavaScript . Cualquier lógica de plantilla se traduce a JavaScript simple y los datos se pueden enviar a la función, que concatena todos los bits y piezas de una manera optimizada.

     

    Un ejemplo de bigote

    La producción del ejemplo anterior se puede realizar utilizando un motor de plantillas, por ejemplo, mustache.js . Esto utiliza la popular sintaxis de plantillas Moustache . Más sobre ellos y sus alternativas más adelante. Echemos un vistazo a un poco de JavaScript para producir algunos resultados:

    var template = 'h1{{title}}/h1ul{{#names}}li{{name}}/li{{/names}}/ul';var data = {"title": "Story", "names": [{"name": "Tarzan"}, {"name": "Jane"}]};var result = Mustache.render(template, data);

    Ahora queremos mostrar esto en la página. En JavaScript simple, esto se podría hacer así:

    document.body.innerHTML = result;

    ¡Eso es todo! Puedes probar lo anterior en tu navegador colocando el script Moustache antes de tu propio código:

    script src="https://raw.github.com/janl/mustache.js/master/mustache.js"/script

    O puede probar este ejemplo en jsFiddle .

    Organizar plantillas

    Si eres como yo, probablemente no te guste tener el HTML en una cadena larga. Esto es difícil de leer y de mantener. Idealmente, podemos colocar nuestras plantillas en archivos separados para seguir teniendo todos los beneficios del resaltado de sintaxis y la capacidad de sangrar adecuadamente las líneas de HTML para facilitar la lectura.

    Pero esto lleva a otra cuestión. Si nuestro proyecto contiene muchas plantillas, no queremos cargar todos esos archivos por separado, ya que esto genera muchas solicitudes (Ajax). Esto sería malo para el rendimiento.

    Escenario 1: Etiquetas de script

    Una solución que se ve con frecuencia es colocar todas las plantillas dentro de scriptetiquetas con un typeatributo alternativo, por ejemplo type=“text/template”(que el navegador ignora al procesarlo o analizarlo):

    script type="text/x-handlebars-template" h1{{title}}/h1 ul {{#names}} li{{name}}/li {{/names}} /ul/script

    De esta manera, puede colocar todas sus plantillas en el documento HTML y evitar todas las solicitudes Ajax adicionales a esas plantillas.

    El contenido de dicha etiqueta de script se puede utilizar más adelante en JavaScript como plantilla. El siguiente ejemplo de código, esta vez usando el motor de plantillas de manillares y un poco de jQuery, usa la scriptetiqueta anterior:

    var template = $('#myTemplate').html();var compiledTemplate = Handlebars.compile(template);var result = compiledTemplate(data);

    También puedes probar este ejemplo en jsFiddle . Viajes y turismo

    El resultado aquí es el mismo que en nuestro ejemplo de Moustache. Los manillares también pueden usar plantillas de Moustache, por lo que aquí usamos la misma plantilla. Sin embargo, hay una diferencia (importante) y es que Manillar utiliza un paso intermedio para obtener el resultado HTML. Primero compila la plantilla en una función de JavaScript (la nombramos compiledTemplateaquí). Luego, esta función se ejecuta utilizando los datos como único argumento, devolviendo el resultado final.

     

    Escenario 2: plantillas precompiladas

    Si bien solo una función para realizar la representación de la plantilla puede parecer conveniente, existen ventajas significativas al dividir el proceso de compilación y representación. Lo más importante es que esto permite que la parte de compilación se realice en el lado del servidor. Podemos ejecutar JavaScript en el servidor (por ejemplo, usando Node), y algunos de los motores de plantillas admiten esta precompilación de plantillas.

    Al juntarlo todo, podemos organizar y servir un único archivo JavaScript (por ejemplo, compiled.js) que contiene varias plantillas precompiladas. Esto podría verse más o menos así:

    var myTemplates = { templateA: function() { ….}, templateB: function() { ….}; templateC: function() { ….};};

    Luego, en el código de la aplicación solo necesitamos completar la plantilla precompilada con datos:

    var result = myTemplates.templateB(data);

    Generalmente, este es un enfoque con un rendimiento mucho mejor que colocar plantillas dentro de scriptetiquetas como se mencionó anteriormente, ya que el cliente puede omitir la parte de compilación. Dependiendo de su pila de aplicaciones, este enfoque no es necesariamente más difícil de lograr, como veremos a continuación.

    Ejemplo de Node.js

    Cualquier script de precompilación de plantilla debe al menos hacer lo siguiente:

    • leer los archivos de plantilla,
    • compilar las plantillas,
    • combine las funciones JavaScript resultantes en uno o más archivos.

    El siguiente script básico de Node.js hace todo eso (usando el motor de plantillas Hogan.js):

    var fs = require('fs'), hogan = require('hogan.js');var templateDir = './templates/', template, templateKey, result = 'var myTemplates = {};';fs.readdirSync(templateDir).forEach(function(templateFile) { template = fs.readFileSync(templateDir + templateFile, 'utf8'); templateKey = templateFile.substr(0, templateFile.lastIndexOf('.')); result += 'myTemplates["'+templateKey+'"] = '; result += 'new Hogan.Template(' + hogan.compile(template, {asString: true}) + ');'});fs.writeFile('compiled.js', result, 'utf8');

    Esto lee todos los archivos de la templates/carpeta, compila las plantillas y las escribe en compiled.js.

    Tenga en cuenta que este es un código muy poco optimizado y no incluye ningún manejo de errores. Aún así, hace el trabajo y demuestra que no requiere mucho código para precompilar plantillas.

    Escenario 3: AMD y RequireJS

    La definición de módulo asincrónico (AMD) está ganando cada vez más fuerza. Los módulos desacoplados suelen ser una excelente manera de organizar una aplicación. Uno de los cargadores de módulos más populares es RequireJS. En una definición de módulo, se pueden especificar dependencias, que se resolverán y estarán disponibles para el módulo real (fábrica).

     

    En el contexto de las plantillas, RequireJS tiene un complemento de "texto" que le permite especificar dependencias basadas en texto. Las dependencias de AMD se tratan como JavaScript de forma predeterminada, pero las plantillas son solo texto (por ejemplo, HTML), por lo que usamos el complemento para eso. Por ejemplo:

    define(['handlebars', 'text!templates/myTemplate.html'], function(Handlebars, template) { var myModule = { render: function() { var data = {"title": "Story", "names": [{"name": "Tarzan"}, {"name": "Jane"}]}; var compiledTemplate = Handlebars.compile(template); return compiledTemplate(data); } }; return myModule;});

    De esta forma, la ventaja reside (únicamente) en la posibilidad de organizar las plantillas en archivos separados. Esto es bueno, pero necesita una solicitud Ajax adicional para obtener la plantilla y aún necesita compilar la plantilla en el lado del cliente. Sin embargo, la solicitud adicional se puede eliminar utilizando el r.jsoptimizador que viene con RequireJS. Esto resuelve las dependencias e "incorporará" las plantillas (o cualquier dependencia) en la definición de este módulo, lo que reducirá enormemente la cantidad de solicitudes.

    La ausencia de un paso de precompilación se puede solucionar de dos formas. Puede que se le ocurra hacer que el optimizador también precompile las plantillas (por ejemplo, podríamos escribir un complemento para r.js). Pero eso también requeriría un cambio en la definición del módulo, ya que estaríamos usando una cadena de plantilla antes de la optimización y una función de plantilla después. Sin embargo, esto no sería muy difícil de manejar, ya sea verificando este tipo de variable o abstrayendo esta lógica (ya sea en el complemento o en la aplicación).

    Ver plantillas

    En ambos escenarios 2 y 3, podemos hacerlo aún mejor si tratamos nuestras plantillas como archivos fuente no compilados. Al igual que los archivos CoffeeScript, Less o SCSS. Podemos monitorear nuestros archivos de plantilla para detectar cambios durante el desarrollo y recompilarlos automáticamente cuando se cambia un archivo, es decir, tal como compilaría CoffeeScript en JavaScript. De esta manera, siempre tratamos con plantillas precompiladas en nuestro código y el optimizador integra sin esfuerzo las plantillas precompiladas en el proceso de compilación.

    define(['templates/myTemplate.js'], function(compiledTemplate) { var myModule = { render: function() { var data = {"title": "Story", "names": [{"name": "Tarzan"}, {"name": "Jane"}]}; return compiledTemplate(data); }; }; return myModule;}

    Consideraciones de rendimiento

    Representar actualizaciones de la interfaz de usuario mediante el uso de plantillas del lado del cliente suele ser el camino a seguir. Aún así, el mejor rendimiento para la carga inicial de la página completa se logra sirviendo esa página en su totalidad. Esto permite que el navegador muestre el HTML tal como está sin necesidad de ningún análisis de JavaScript ni solicitudes adicionales de datos. Esto podría ser un desafío, especialmente para páginas que son dinámicas y requieren los mejores tiempos de carga inicial posibles. Luego, lo ideal es que las plantillas se desarrollen y reutilicen en el cliente y en el servidor para respaldar el mejor rendimiento y seguir siendo mantenibles.

    Dos preguntas a considerar aquí son:

    • ¿Qué parte de mi aplicación es mayoritariamente dinámica y qué parte requiere los mejores tiempos de carga iniciales posibles?
    • ¿Quiere trasladar el procesamiento al cliente o debería ser el servidor quien haga el trabajo pesado?

    La respuesta sólo puede darse midiendo diferentes enfoques. Sin embargo, al utilizar plantillas precompiladas, el cliente normalmente no tiene dificultades para renderizarlas sobre la marcha. Y en caso de que desee reutilizar plantillas en el cliente y el servidor, encontrará que una sintaxis de plantilla sin lógica es la más versátil.

    Conclusión

    Hemos visto muchos puntos fuertes de las plantillas del lado del cliente, entre ellos:

    • Los servidores de aplicaciones y las API son mejores para servir solo los datos (es decir, JSON); Las plantillas del lado del cliente encajan perfectamente.
    • HTML y JavaScript coinciden naturalmente con las habilidades de los desarrolladores del lado del cliente.
    • El uso de plantillas impone una buena práctica de separar la presentación y la lógica.
    • Las plantillas se pueden precompilar y almacenar en caché por completo, lo que deja solo los datos reales que se actualizarán desde el servidor.
    • Mover la fase de renderizado del servidor al cliente puede afectar positivamente el rendimiento.

    Hemos estado analizando bastantes aspectos de las plantillas (del lado del cliente). Esperemos que a estas alturas comprenda mejor el concepto y por qué debería utilizarlo.

    Otras lecturas

    • Una introducción a JavaScript de pila completa
    • Viaje a través de la jungla MVC de JavaScript
    • Bibliotecas JavaScript útiles y complementos jQuery

    (cp, señor)Explora más en

    • Codificación
    • javascript
    • Navegadores
    • Plantillas
    • HTML





  • Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Plantillas del lado del cliente

    Plantillas del lado del cliente

    Índice ¿Por qué lo usarías? Primeras impres

    programar

    es

    https://aprendeprogramando.es/static/images/programar-plantillas-del-lado-del-cliente-809-0.jpg

    2024-05-20

     

    Plantillas del lado del cliente
    Plantillas del lado del cliente

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Top 20