linkedin - Ejemplo básico de las plantillas del lado del cliente con Dust.js

client-side-templating

Question

Esta es mi primera incursión en las plantillas del lado del cliente y quiero asegurarme de que lo estoy entendiendo y utilizándolo correctamente. Después de leer este blog de ingeniería de LinkedIn , decidí dust.js lugar de mustache o handlebars . Tenga en cuenta que esta publicación de stackoverflow respondió a muchas de mis preguntas, pero todavía tengo algunas cosas que quiero aclarar.

En el entorno en el que trabajo, no tengo acceso a nada en el lado del servidor, por lo que todo lo que creo tiene que poder ejecutarse completamente en el navegador del cliente. Para este ejemplo, intentaré volver a crear este ejemplo de código del Tutorial de Polvo de LinkedIn .

Incluyo dust-full.js en lugar de dust-core.js porque voy a compilar la plantilla sobre la marcha:

<script src="js/dust-full.js"></script>

Aquí está el HTML:

<script id="entry-template">
{title}
<ul>
{#names}
<li>{name}</li>{~n}
{/names}
</ul>
</script>
<div id="output"></div>

Y el JavaScript (usando jQuery):

$(document).ready(function () {
var data = {
"title": "Famous People",
"names" : [{ "name": "Larry" },{ "name": "Curly" },{ "name": "Moe" }]
}
var source = $("#entry-template").html();
var compiled = dust.compile(source, "intro");
dust.loadSource(compiled);
dust.render("intro", data, function(err, out) {
$("#output").html(out);
});
});

Esto parece funcionar bien, como se puede ver en este jsfiddle .

Un par de preguntas:

1. ¿Por qué debería estar contenida la plantilla dentro de las etiquetas de script? ¿Por qué no simplemente incluirlo en un div con id = "entry-template" y luego reemplazar el html dentro de ese durante el dust.render (), como en este violín modificado ?

2. ¿Qué hace " dust.loadSource (compilado); "? En los documentos dice "Si incluye la cadena ''compilada'' como parte de un bloque de script de JS que carga, entonces se definirá y registrará la plantilla ''intro''. Si desea hacerlo de inmediato," llámelo, Sin embargo no entiendo lo que eso significa. Me he dado cuenta de que si quito esa línea, entonces no funciona, así que me gustaría entenderla.

3. Una vez que esté satisfecho con mi plantilla y lo finalice, ¿cómo debo compilarlo para que importe el light -core.js en lugar de que el navegador lo compile en cada carga de página? ¿Hay una ventaja significativa para hacer esto o debo dejarlo como está con dust-full.js ?

4. De manera más general, ¿parece esto una forma apropiada / útil de implementar polvo (o cualquier marco de plantilla para esa materia) o simplemente estoy fuera de lugar?

Gracias por adelantado.

Answer 1

1. No debería tener que contener la plantilla en las etiquetas de script, su segunda forma es mejor.

2. loadSource ejecutará la salida compilada de su plantilla, que incluye el registro para que otras plantillas y dust.render puedan hacer referencia a la cadena de salida compilada a través de su nombre ("introducción" en este caso).

3. Esto implica la compilación previa de sus plantillas antes de que incluso abra el navegador. Por lo tanto, es posible que tenga una carpeta que tenga todas sus plantillas como archivos .tl. En algún paso de compilación, compilaría todas estas plantillas (usando dust.compile) y guardaría la salida como archivos .js. Entonces el navegador realmente cargaría esos archivos .js. Esto también elimina la necesidad de dust.loadSource. La ventaja aquí es no tener que incluir el compilador y el analizador, que suman hasta ~ 3000 líneas de código. El tamaño de la biblioteca de polvo va de 4000 líneas de código a solo 800 líneas de código. EDITAR: Además, como mencionó, no está compilando plantillas sobre la marcha en el navegador, por lo que también será una gran ganancia de rendimiento.

4. Yo diría que, aparte de perder el paso de compilación que mencioné anteriormente, estás en el camino correcto.

Answer 2

1. Si lo coloca en un div , el marcado se renderizará tan pronto como se cargue la página y con la sintaxis de polvo {placeholder} . Luego, una vez que ocurra la representación del lado del cliente, se reemplazará de repente con el contenido completamente representado. En un ejemplo simple, esto puede suceder tan rápido que no lo notará. Sin embargo, dependiendo del tiempo que demore en descargar las plantillas, las bibliotecas de JS en polvo, buscar el JSON (si aún no está incrustado en la página), el rendimiento de JS del navegador y otras cosas que suceden en la página, este interruptor puede ser muy notable para un usuario, lo cual no es una buena experiencia.

2. Cuando compila una plantilla de polvo, la salida es una cadena que contiene una función de JavaScript. Se verá algo así como:

   (function () {dust.register ("intro", body0); function body0 (chk, ctx) {/ * [...] * /}}) ();

   Cuando pasa esta cadena a dust.loadSource, todo lo que hace es eval , ejecutando esta función de auto-llamada. El resultado es que se ejecuta la llamada dust.register , que asocia la función body0 con el nombre intro en dust.cache . Después de eso, cada vez que llamas dust.render("intro"...) , dust busca la plantilla de intro en dust.cache y ejecuta la función asociada con él.

3. Almacene la salida de dust.compile en un archivo .js , como intro.js para el ejemplo anterior. Luego puede incluir dust-core.js e intro.js en la página como cualquier otro archivo JavaScript (por ejemplo, en script tags o mediante cargadores).

4. Por lo general, almacena cada plantilla de polvo en un archivo separado, como intro.tl y utiliza algún tipo de sistema de compilación (por ejemplo, http://gruntjs.com/ ) para compilarlo automáticamente en un archivo .js cada vez que cambia. Luego, concatena todos los archivos .js generados en un solo archivo (grunt también puede hacer esto) y carga eso en la página en una etiqueta de script .