Intereting Posts

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

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

Задний план:

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

У меня есть одна страница в приложении, которая отображает подробности об одном теге по отношению к одному пользователю. Скажем, пользовательский « bob » и тег « footag ». На этой странице я показываю два списка: все люди, которые отметили bob с помощью «footag» и всех людей bob, отметили «footag». назовем их

и

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

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

Вопрос

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

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

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

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

Благодаря!

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

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

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

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

Greetz

back2dos

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

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

 
  • foo
  • bar
  • baz
  • чтобы:

     
  • foo2
  • bar2
  • baz2
  • когда вы получаете JSON:

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

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

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

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

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