Лучшая практика: загрузка рендеринга html или json?

Привет, ребята, у меня вопрос, который кажется глупым, но я не могу сказать, почему.

Справочная информация:

Представьте себе webapp с пользователями и тегами. Пользователи отмечают друг друга.

У меня есть одна страница в приложении, которая отображает подробности об одном теге по отношению к одному пользователю. Пусть говорят " bob" и тег footag. На этой странице я показываю два списка: все люди, которые отметили bob с помощью "footag" и всех людей bob, отметили "footag". назовите эти <div id="received'> и <div id="sent">

Предположим, что для этого представления URL /users/bob/tags/footag

Естественно, эти списки длинны - я не хочу загружать весь список на просмотр страницы. Поэтому я загружаю первую десятку для каждого.

Вопрос

Теперь я могу предоставить динамический пейджинг для каждого из списков одним из двух способов:

Получить данные для следующих 10 пользователей как json. Напишите js для рендеринга этих данных, заменив содержимое div.
Получите отсканированный "фрагмент" html из другого четко определенного URL-адреса на моем сервере, скажем /users/bob/tags/footag/received?page=1. Я получаю его асинхронно и просто заменяю содержимое соответствующего <div>.

Итак, в одном случае я извлекаю данные и обрабатываю их через JS в браузере, а другой - получаю данные и просто выкладываю их в документ.

Есть ли причина не использовать # 2? Я не могу себе представить, но я полагаю, что могут быть аспекты безопасности, которые я не рассматриваю, или производительность, или что-то еще. Я бы предпочел сделать # 2, поскольку это значительно упростило мою жизнь.

Спасибо!

Ответ 1

У меня есть приложение вроде этого - я использую оба метода.

Я использую ваш метод # 1 для обновления полей, которые не являются смежными (например, поля ввода по всему месту), но я использую ваш метод # 2 для обновления табличных данных, вроде ваших списков.

Я бы придерживался №2 для вашего дела.

Ответ 2

я бы пошел С# 1... так что вы действительно получите данные, а не только некоторые HTML... это будет просто краткая структура объектов JavaScript, а не какая-то строка, поэтому вы можете оценить данные по своему усмотрению, кешировать его, использовать его для поиска и т.д.... чем больше работы выполняется на стороне клиента, тем лучше, тем лучше, чем вы масштабируете приложение... у вас есть 1 сервер, или, возможно, 2-10 или я не знаю, но у вас 10-10000 клиентов...

Greetz

back2dos

Ответ 3

Я лично использовал бы метод # 2. Зачем тратить время на парсинг на стороне клиента, который может быть легко и лучше, если использовать серверный язык? Вместо того, чтобы создавать массив, а затем преобразовывать его в json, было бы гораздо лучше просто пропустить результаты и эхо-HTML.

Ответ 4

Я бы оценил его в нескольких браузерах, но я подозреваю, что # 1 (передача как JSON) может оказаться быстрее. С помощью этого метода вы можете просто заменить значения для существующих узлов DOM. Например. (очень упрощенное) изменение (непосредственно с помощью DOM-манипуляции):

<li>foo</li>
<li>bar</li>
<li>baz</li>

<li>foo2</li>
<li>bar2</li>
<li>baz2</li>

когда вы получаете JSON:

["foo2", "bar2", "baz2"]

Таким образом, вы не создаете новые узлы DOM без необходимости. Другим преимуществом является то, что JSON API более "аппетитный", если позже вы решите сделать его общедоступным в той или иной форме.

Ответ 5

хорошо, кроме небольших накладных расходов на форматирование, загружаемое с сервера, что может сделать его немного медленнее для большого количества данных, я не вижу недостатков. И поскольку рендеринг javascript, вероятно, будет слишком медленным, я бы пошел С# 2.

Ответ 6

Я говорю # 1 для большинства случаев. Если вы хотите добавить кнопку "next/prev" за пределами обновляемого div, вы можете использовать JS для определения, когда включать/отключать их. Использование # 1 дает вам большую гибкость и дополнительно отделяет данные от презентации.

Производительность и "простота разработки" на мой взгляд пренебрежимо мала. Производительность не слишком велика для небольших "кусков" данных (при условии, что ваш JS включен в сферу здравомыслия) и "простота разработки" не является большим фактором, учитывая, что это легче поддерживать.