Лучшая практика: загрузка рендеринга HTML или JSON

Question

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

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

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

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

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

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

Вопрос

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

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

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

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

Спасибо!

Answer 1

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

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

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

Answer 2

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

Greetz

*

back2dos 1005 *

Answer 3

Я бы проверил его в нескольких браузерах, но я подозреваю, что # 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 более «аппетитен», если позже вы решите сделать его публичным в той или иной форме.

Answer 4

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

Answer 5

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

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

Answer 6

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