Визуализация частичного просмотра на сервере или отправка данных JSON и рендеринга шаблона на клиенте

Question

Мне было интересно, что было бы хорошим подходом (или рекомендуемым подходом) для визуализации частичных представлений в веб-приложении.

У меня есть требование, когда мне нужно загружать данные на уже отрисованную страницу, используя AJAX,вроде как ссылка «Загрузить больше ...» в конце страницы, которая получает больше информации с сервера и отображает ее в нижней части страницы.

Два вариантаНа данный момент я играю с ответом AJAX:

1. Возвращает представление данных в формате JSON и использует библиотеку шаблонов на стороне клиента (например, шаблоны jQuery) или просто простой JavaScript, чтобы включить JSON.в HTML и добавьте в конец страницы
2. Визуализируйте частичное представление на сервере (в моем случае используя grails 'render template:'tmplt_name') и отправьте его по проводам и просто добавьте результат в нижнюю частьстраница

Есть ли другие способы сделать это?Если нет, учитывая вышеперечисленные варианты, которые были бы лучше с точки зрения обслуживания, производительности и тестируемости?В одном я уверен, что маршрут JSON (в большинстве случаев) будет использовать меньшую пропускную способность, чем отправка html по проводам.

Answer 1

На самом деле это действительно интересный вопрос, потому что он раскрывает некоторые интересные дизайнерские решения.

Я предпочитаю рендеринг частичных шаблонов, потому что это дает моим приложениям возможность меняться со временем.Если мне нужно перейти с <table> на <div> с диаграммой, это легко включить в шаблон.Имея это в виду, я рассматриваю почти каждую страницу как совокупность множества небольших шаблонов, которые могут измениться.Стандартные леса Grails 2.0 сместились в сторону этого типа подхода, и это хорошая идея.

Вопрос в том, должны ли они быть шаблонами на стороне клиента или на стороне сервера, суть проблемы.

Шаблоны на стороне сервера сохранят чистоту разметки при начальной загрузке страницы.Даже если вы используете что-то вроде Усы из ICanHazJS , вам, скорее всего, нужно иметь пустой элемент на странице (что-то с вашим шаблоном), стилизовать его соответствующим образом и работать с ним вJavascript для того, чтобы получить обновленную информацию.

Недостатки

• "болтливые" приложения
• большие конверты по проводам (ответы включают HTML, который можно считать статическим)
• более медленный пользовательский интерфейсвремя отклика

Преимущества

• Подходит для людей с большим языковым опытом на стороне сервера
• Возможно, проще манипулировать или изменять в среде на стороне сервера (например, вернуть страницу, содержащую несколько шаблонов, которые загружаются и включаются программным способом)
• Хранит большую часть содержимого приложения "в одном месте"

Клиентские шаблоны могут реально уменьшить серверЗагрузите, однако.Они делают приложение «менее понятным», так как потенциально вы можете минимизировать количество обратных вызовов на сервер, отправляя обратно большие коллекции JSON (с тем же числом байтов или меньше, которое будет обрабатываться HTML вшаблонная схема на стороне сервера).Они также делают пользовательский интерфейс очень быстрым для пользователей, так как нажатие на ссылку «обновить» не обязательно должно выполнять обход AJAX.Кто-то сказал:

Энтони Иден @aeden 10 декабря Ответить Ретвиты Фаворит · Откройте будущее веб-приложений: запросы обрабатываются функциями, логика всегда асинхронна и HTML никогда не генерируется на сервере.

Недостатки

• Не подходит для SEO (несемантические посторонние элементы пользовательского интерфейса при начальной загрузке страницы)
• Требуется некоторое количество javascript foo (для управления элементами)

Преимущества - Отзывчивый - Меньшие конверты

Тенденции, похоже, движутся в сторону шаблонов на стороне клиента, особенно с мощью, предоставляемой дополнениями HTML5 (такими как <canvas>) ... но еслииспользование их требует, чтобы вы полагались на технологии, с которыми вы не очень хорошо знакомы, и вы чувствуете себя более комфортно с партиалами Grails, возможно, стоит начать с них и исследовать рефакторинг в сторону шаблонов на стороне клиента на основе производительности и других проблем позже.

Answer 2

Я бы сказал, что это зависит от того, сколько данных вы отправляете по проводам, когда вы это делаете. Если вы реализуете функцию «загрузить больше», то кажется, что вам не понадобится 5 секунд, чтобы что-то загрузить. Изображения Google - хороший пример того, как быстро эта функция должна быть. Если вы знаете, что у вас никогда не будет такого большого количества данных, то рендеринг партиала на сервере может быть более чистым, но если ваши требования изменятся, то будет хлопотно вернуться к первому подходу. Короче говоря, я бы сказал, что первый подход позволяет более эффективно управлять аварийными ситуациями и определять, сколько времени требуется для загрузки большого количества данных. Я бы сказал, что в общем случае рекомендуется снимать нагрузку с сервера, когда это возможно, даже если это немного неудобно на стороне клиента для разработчика.

Answer 3

, на мой взгляд, второй вариант частичное рендеринг лучше, потому что, если вы получаете данные json , вы должны манипулировать ими как набор стилей, создание элементов, набор значений и тому подобное В соответствии с необходимостью сразу после того, как вы получите ответ ajax в javascript, но если вы визуализируете частичное, вы можете спроектировать свое представление в этом частичном ранее и сохранить готовность и просто импортировать, используя вызов ajax, чтобы не было никакой ответственности за обработку данных ответа.