Renderizar vista parcial en el servidor o enviar datos json y plantilla de representación en el cliente

Question

Me preguntaba cuál sería un buen enfoque (o enfoque recomendado) para representar vistas parciales en una aplicación web.

Tengo un requisito en el que necesito para cargar datos en una página ya dictada el uso de AJAX, como una especie de "Cargar más ..." enlace al final de la página que agarra más información desde el servidor y lo muestra al final de la página.

Las dos opciones estoy jugando con en el momento de la respuesta AJAX son

1. Volver una representación JSON de los datos, y utilizan una biblioteca de plantillas lado del cliente, (por ejemplo, las plantillas jQuery) o simplemente Javascript convertir el JSON en HTML y anexarlo a la parte inferior de la página
2. Renderizar la vista parcial en el servidor (en mi caso usando grails 'render template:'tmplt_name') y enviarla a través del cable y anexar el resultado al final de la página

¿Hay otras formas de hacer esto? De lo contrario, dadas las opciones anteriores, ¿cuál sería mejor en términos de mantenimiento, rendimiento y capacidad de prueba? Una cosa de la que estoy seguro es que la ruta JSON (en la mayoría de los casos) usará menos ancho de banda que el envío de html a través del cable.

Answer 1

Esto es realmente una pregunta realmente interesante, ya que expone algunas decisiones de diseño interesantes.

Prefiero la representación de plantillas parciales porque les da a mis aplicaciones la capacidad de cambiar con el tiempo. Si necesito cambiar de <table> a <div> con un gráfico, es fácil de encapsular en una plantilla. Con esto en mente, veo casi todas las páginas como un agregado de muchas plantillas pequeñas, que podrían cambiar. El andamiaje predeterminado de Grails 2.0 se ha movido hacia este tipo de enfoque, y es una buena idea.

La cuestión de si deberían ser plantillas del lado del cliente o del lado del servidor es el quid de la cuestión.

Las plantillas del lado del servidor mantienen su limpiador de marcas en la carga de la página inicial.Incluso si utiliza algo como Mustache de ICanHazJS, debe tener un elemento vacío en la página (algo con su plantilla), modelarlo adecuadamente y trabajar con él en Javascript para actualizar su información.

Inconvenientes

• aplicaciones "hablador"
• sobres más grandes a través del cable (respuestas incluyen HTML, que puede considerarse estática) Tiempo de
• más lenta respuesta de la interfaz de usuario

Beneficios

• Good fo r personas con mucha experiencia en el idioma del lado del servidor
• Tal vez más fácil de manipular o modificar en un entorno del lado del servidor (p. devolver una página intercalada con varias plantillas, que se cargan mediante programación e incluidos)
• mantiene la mayor parte de las cosas de la aplicación "en un solo lugar"

plantillas del lado del cliente puede realmente reducir la carga del servidor, sin embargo. Hacen que una aplicación sea "menos explícita", ya que potencialmente podría minimizar el número de llamadas al servidor enviando colecciones más grandes de JSON (en la misma cantidad de bytes, o menos, que tomaría HTML en un esquema de plantilla del lado del servidor). También hacen que la experiencia de interfaz de usuario sea muy rápida para los usuarios, ya que al hacer clic en un enlace de "actualización" no es necesario realizar un viaje de ida y vuelta de AJAX. Algunos han dicho:

Anthony Eden @aeden 10 Dic Responder favorito Retweeteado · Abrir el futuro de las aplicaciones web: peticiones son manejadas por funciones, la lógica siempre es asíncrona, y HTML no se genera en el servidor.

Inconvenientes

• No es muy bueno para el SEO (elementos de la interfaz extraña ONU-semántica de carga de la página inicial)
• requiere un poco de foo Javascript (para manipular elementos)

Beneficios - Responsivo - Sobres más pequeños

Tendencia s parecen estar avanzando hacia las plantillas del lado del cliente, especialmente con la potencia expuesta por las adiciones HTML5 (como <canvas>) ... pero si aprovecharlas requiere que confíe en tecnologías con las que no está muy familiarizado, y se siente más cómodo con Grails parciales, puede valer la pena comenzar con esos e investigar la refactorización hacia las plantillas del lado del cliente en función del rendimiento y otras inquietudes posteriores.

Answer 2

en mi opinión, la segunda opción Rendering parcial es mejor ya que si se obtiene un dato JSON que se supone que manipularla como conjunto estilo, crear elementos, valores ajustados y algo similar como por la necesidad justo después de Obtenga una respuesta ajax en javascript, pero si hace un parcial, puede diseñar su vista en ese parcial antes y mantenerlo listo y solo importar usando una llamada jaja para que no haya responsabilidad de manejar los datos de respuesta.

Answer 3

Yo diría que depende de la cantidad de datos que está enviando a través del cable como usted lo expresó. Si está implementando una función de "cargar más", parece que no le gustaría tomar 5 segundos para cargar algo. Google images es un buen ejemplo de qué tan rápida debe ser esa característica. Si sabes que nunca tendrás tantos datos, entonces renderizar el parcial en el servidor podría ser más limpio, pero si cambias los requisitos, entonces es una molestia volver al primer enfoque. En resumen, diría que el primer enfoque permite un mayor control de desastres en cuanto a cuánto tarda una carga más en cargar una gran cantidad de datos. Yo diría que también es una buena práctica general retirar el servidor del servidor cuando sea posible, incluso si es un inconveniente del desarrollador para el lado del cliente.