Pregunta ¿Cuáles son los casos de uso de jsdom?


Después de leer esto Las micro plantillas están muertas artículo. Me he vuelto curioso

  1. Si el uso del DOM en el servidor da como resultado un código más limpio y más fácil de mantener, entonces la creación de plantillas.
  2. Si es más eficiente usar jsdom en lugar de un motor de plantillas.
  3. Cómo factorizar jsdom en la Vista de una configuración MVC estándar.

Y, en general, ¿en qué situaciones sería mejor utilizar una abstracción de DOM del lado del servidor, como jsdom en lugar de un motor de plantillas, como EJS o jade.

La pregunta es específica para node.js y otros SSJS


32
2018-05-23 19:02


origen


Respuestas:


  1. Es una bonita abstracción que combina con un lado del cliente que los ingenieros toman sobre cómo se construye y se modifica el dom. En ese sentido, es "más limpio" porque hay un modelo mental. También es bueno porque no tenemos que mezclar un sinfín de sintaxis dispares de un lenguaje de plantillas además de un marcado declarativo limpio como es el caso incluso con el sistema de plantillas más "estúpido", como el bigote.

  2. Yo NO diría que es más eficiente usar jsdom para crear plantillas. Ve a echar un vistazo a google wrt para 'pérdidas de memoria con jsdom', por ejemplo. jsdom es radical, y es súper útil para tareas como proyectos de fin de semana para rastrear sitios, realizar tareas no relacionadas con el servidor, pero creo que es lento como una mierda desde una perspectiva de servidor web de alto rendimiento.

  3. Hay mil millones de formas de factorizar esto. Ningún método ha surgido como una forma "estándar". Una forma que he visto es enviar una 'plantilla' vacía, es decir, un bloque de html que representa un modelo de alguna manera, y luego usar eso para arrancar la construcción de su vista final desde un modelo. De ese artículo, por ejemplo:


<li class="contact" id="contact-template">
    <span class="name"></span>
    <p class="title"></p>
</li>

Esta es la 'vista' en el respeto clásico. En la aplicación web típica, podría parecerse más a:

<li class="contact">
    <span class="name"><?= $name ?></span>
    <p class="title"><?= $title ?></p>
</li>

Para usar mvc, se configura un controlador que es vagamente consciente de la semántica de la vista anterior y el modelo que representa. Esta vista se analiza en / a DOM y se accede a través de su motor de selección favorito. Cada vez que el modelo que esto representa cambia, puede usar cambios de eventos o devoluciones de llamada para actualizar la vista. Por ejemplo:

Imaginemos que el 'modelo' dispara un evento de 'cambio' cada vez que cambia una propiedad.

controller = new Controller({ 
    view: $('#contact-template').clone(), // Assume jquery or whatever
    model: aContact 
});

// Assume some initialization that sets the view up for the first time
// and appends it to the appropriate place. A la:
// this.view.find('.name').text(model.name);
// this.view.find('.title').text(model.title);
// this.view.appendTo('#contacts')

controller.on('model.name.change', function(name){
    this.view.find('.name').text(name);
});

Estos son los sistemas que Weld y Backbone.js hacen por ti. Todos tienen diferentes grados de suposiciones sobre dónde se está llevando a cabo este trabajo (lado del servidor, lado del cliente), qué marco está usando (jquery, mootools, etc.) y cómo se están distribuyendo sus cambios (REST, socket. io, etc.)

Editar

Algunas cosas realmente útiles que puede hacer con jsdom giran en torno a las pruebas de integración y spidering:

Personalmente, me gustaría ver un proyecto que tomara el enfoque de tobi, pero lo mapeo encima de algo como https://github.com/LearnBoost/soda de tal manera que podemos hacer pruebas de selenio basadas en la nube sin selenese (ya que en realidad, es una mierda).


12
2018-05-23 22:12



Bueno, realmente necesitaba JSDom para un pequeño proyecto que construí durante el fin de semana en node.js. Por lo tanto, en mi servidor, tuve que aceptar una URL para recuperar, tomar todo el HTML de la URL determinada, analizarlo y mostrar imágenes al usuario para que el usuario pudiera seleccionar una miniatura de esa URL. (Algo así como cuando sueltas un enlace en el cuadro de entrada de Facebook) Entonces, utilicé un módulo llamado Solicitud que me permite buscar HTML en el lado del servidor. Sin embargo, cuando ese HTML llegó a mi programa, no tuve forma de recorrerlo como lo hace con javascript en el lado del cliente. Debido a que no había DOM real, no podría decir document.getElementById('someId'). Por lo tanto, JSDom fue útil al darme un DOM "improvisado" que me permitió atravesar el HTML devuelto. Ahora, a pesar de que todavía estaba en el lado del servidor, JSDOM creó un window objeto muy similar al objeto ventana en el navegador, y creó un DOM a partir del HTML devuelto. Ahora, incluso en el servidor, pude obtener todas las imágenes llamando window.$('img'). Podría apuntar y analizar los elementos como normal. Entonces, este es solo un problema donde JSDom resultó ser la solución, pero funcionó increíblemente bien. Espero que esto ayude a algunos!


12
2018-05-23 20:03



Algunos vienen a la mente:

  1. Compartir vistas / controladores entre el servidor y el navegador
  2. Data mining / crawling / processing
  3. Transformación para fragmentos de HTML usados ​​en AJAX / cosas en tiempo real
  4. Separación absoluta de lógica y contenido al evitar etiquetas de plantilla

Y para responder tus preguntas:

  1. tal vez. Muchas cosas afectan la calidad del código, pero es un paso en la dirección correcta
  2. no, los motores de plantillas siempre serán más rápidos, ya que pueden precompilar plantillas
  3. esto probablemente justifica una nueva pregunta?

1
2018-05-28 04:05



El punto 2 de tu pregunta puede ser respondido por esta plantilla de prueba:

ir http://jsperf.com/dom-vs-innerhtml-based-templating/300

  • haga clic en el botón "Ejecutar pruebas".

  • sea ​​paciente, compara la soldadura vs. mucho de otros motores de plantilla y le da los puntos de referencia actuales ...


1
2018-04-01 20:02