Сколько контента, заменяемого вызовом AJAX, является слишком большим?
Я сталкиваюсь с распространенной проблемой при разработке AJAX. По возможности я стараюсь просто обновлять данные в существующем макете, а не сам макет. Например, возьмите div ниже:
<div id = "content-5">Here is some content</div>
Я бы получил обновленное значение для content-5 с сервера и просто заменил бы содержимое content-5 значением. Это имеет смысл для простой замены данных, когда значение всегда будет отображаться в чистом виде.
Иногда содержимое более сложное, и мне действительно нужно получить больше, чем просто необработанные данные ... может быть, есть какая-то логика, чтобы определить, как отображается значение, и, возможно, стиль должен отличаться в зависимости от данных внутри. В этом случае я обычно создаю HTML на стороне сервера и вставляю HTML в элемент, а не просто необработанные данные.
Пример: поле статуса из контроллера возвращается как «завершено», но из проектной документации «завершено» должно показывать пользователю текст «Доступен», и его стиль должен отличаться от других статусов.
Выполнение этого в Javascript потребует некоторых глубоких знаний о представлении, которые, вероятно, уже обрабатываются на уровне шаблона. Конечный результат будет таким же (фрагмент кода ниже), но разница в том, что возможно некоторое дублирование кода и гораздо более сложный уровень Javascript.
<div id = "content-5"><span class = "success">Available</span></div>
В обязательном порядке возникает требование, чтобы система также обрабатывала «новое» содержимое. Самое простое решение для реализации - просто получить весь контент одновременно, чтобы мне не приходилось обрабатывать дополнительную сложность внедрения нового элемента вместо простой замены существующего контента.
Итак, я создаю новый шаблон, оборачиваю содержимое в другой элемент с идентификатором и массово заменяю все блоки содержимого одновременно в любое время при каждом изменении.
<div id = "allContent">
<div id = "content-1">Some content A</div>
<div id = "content-2">Some content B</div>
<div id = "content-3">Some content C</div>
<div id = "content-4">Some content D</div>
<div id = "content-5">Some content E</div>
</div>
В какой-то момент я должен задаться вопросом: а где же линия? В какой-то момент мне кажется, что я просто заменю всю страницу запросом AJAX. Неужели это будет проблемой?
Я понимаю, что это может быть довольно субъективно, но каковы некоторые хорошие стратегии для определения, до какого уровня следует заменять контент на AJAX? По возможности, я предпочитаю замену только данных, так как это делает контроллеры AJAX очень простыми. Замена больших фрагментов HTML из шаблона кажется самым простым для решения более сложных проблем с макетом и дизайном, а также кажется, что его можно было бы легче поддерживать. Есть ли другие варианты, которые я не рассматривал?
Я ожидаю, что будет некоторое обсуждение программных манипуляций с DOM, но мне лично это очень не нравится. Код в итоге выглядит ужасно и действительно начинает интегрировать слишком много макета и дизайна в слой JS, что мне нравится. Поскольку я обычно работаю с какими-либо библиотеками шаблонов (будь то необработанный PHP, шаблоны PHP, такие как Smarty или JSP в Java), кажется, имеет смысл оставить там как можно больше визуального дизайна.
РЕДАКТИРОВАТЬ
Судя по первым нескольким ответам, похоже, что это читается как попытка удержать пользователя на одной странице, но перемещаться по сайту или иным образом радикально менять страницу при каждом обновлении. Вопрос больше в том, как определить, где должна происходить работа макета для вызовов AJAX и является ли приемлемой практикой изменение больших фрагментов кода с помощью запроса AJAX, зная, что код замены может выглядеть почти идентично тому, что было там. перед.
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 6
Полное личное мнение ex nihil, мое практическое правило - изменить не более 1 единицы "панели" или 33% страницы, в зависимости от того, что меньше.
Основанием для этого является то, что пользователь должен иметь возможность четко распознать, что предыдущее состояние страницы связано с новым состоянием - как бы вы себя почувствовали, если бы вас внезапно телепортировали в здание справа от вас? Будьте осторожны со своим бедным пользователем.
Есть также серьезные технические вопросы о преимуществах перемещения и вставки в основном данных на страницу, что, на мой взгляд, является своего рода анти-шаблоном AJAX. Какие преимущества дает AJAX, если вы собираетесь это делать?
Ваш конкретный вопрос, кажется, зависит от предположения, что ответ, полученный от вашего запроса AJAX, - это не «просто» данные. Мне это кажется неправильным с точки зрения разделения проблем: я бы ожидал, что на странице будет вся необходимая информация о макете, сам ответ AJAX не предоставит ничего, кроме глупых данных / разметки, и обработчик событий JS, который создал просьба сшить их вместе в стиле MVC. В этом отношении, я думаю, да, вы делаете слишком много.
(под панелью я подразумеваю один логический элемент дизайна - меню, ленту, панель метаданных элемента и т. д.)
edit: теперь, когда я думаю об этом, я думаю, что страница профиля пользователя SO нарушает мое эмпирическое правило с этими щелчками вкладок
Да, изменить всю страницу и сделать так, чтобы она выглядела совершенно не связанной с ее предыдущим состоянием, на самом деле не то, что я описывал, но тем не менее отличный ответ!
извините, я должен признаться, что меня больше волновало название, чем вопрос под ним. Я снова отредактировал в свете этого.
«Мне это кажется неправильным с точки зрения разделения проблем» Что беспокоит Javascript? Разве не лучше позволить серверной стороне повторно отображать сложные макеты пользовательского интерфейса вместо того, чтобы дублировать эти усилия в JS? Это действительно вопрос!
@Beau Simensen - Мне придется вернуться к этому, когда мне не нужно ложиться спать. Тем не менее, он вызовет общий ответ: S
В зависимости от того, хотите ли вы, чтобы люди могли ссылаться на / закладку и т. д. На текущую страницу, вы можете перейти в браузер пользователя.
Это не касается некоторых приложений, таких как GMail и т. д., И они никогда не обновят страницу.
Что касается себя, я склонен думать, что навигация в браузере при переходе в другое логически другое место - это хорошая практика. например. профиль человека или список его сообщений.
Извините, если это расплывчато, это скорее субъективно :-)
Хороший ориентир для чего-то подобного - спросить себя: «Является ли это динамическое приложение« контентом »или оно является контентом-контентом?» Ваш вариант использования звучит как содержимое приложения, которое будет меняться с каждым пользователем. Это, наверное, лучшее место для Ajax, но всегда приятно иметь не один молоток. Вы не хотите делать слишком много на одной странице. Например, если одна часть сломается, это может расстроить пользователя.
Везде, где вы просматриваете реальное содержимое страницы или что-либо, где информация статична, я настоятельно рекомендую избегать использования JavaScript, так как он рискует стать невидимым для поисковых систем. Убедитесь, что все, что связано с подобной информацией, доступно для сканирования. Первый шаг к этому - динамическая генерация на стороне сервера, а не на стороне браузера.
Статический контент - это основная причина, по которой я склоняюсь к обновлению фрагментов HTML через. существующие шаблоны для более сложных макетов. Шаблон уже существует и может отображаться для людей, не использующих JS, и обновления могут доставляться с использованием шаблона в ответе AJAX. Вопрос в том, хорошая ли это идея?
Я бы избегал всего, что требует AJAX для нединамического контента, который вы хотели бы искать в Google. В идеале каждый фрагмент контента должен иметь свой собственный URL-адрес. Также никогда нельзя найти два фрагмента контента по одному и тому же URL-адресу.
Мой комментарий сбивал с толку. Контент является динамическим, но страница изначально отображается вне шаблона и остается «статической» для Google или пользователей без Javascript. AJAX может использовать тот же шаблон при изменении данных.
Можно иметь динамический контент, отображаемый на стороне сервера (доступный для SE), а затем накладывать ajax-вызовы поверх этого для расширенной функциональности. Вопрос касается природы этих вызовов ajax. Ajax не означает автоматически «не дружественный к SE». Хороший совет, но не суть вопроса.
Если вы используете шаблоны Smarty для создания страницы, просто фрагментируйте шаблон на различные значимые разделы - news.tpl, email.tpl, weather.tpl - и пусть master.tpl создает структуру страницы и вызывает дочерние шаблоны.
Затем, если вы, например, используете вызов AJAX, запускаемый по таймауту для обновления новостей, вы можете просто вызвать сервер, втиснуть необходимые данные в news.tpl и вернуть результаты в div новостей, который вы настроили с помощью master. .tpl. Таким образом, ваш макет новостей всегда соответствует шаблону news.tpl. (Если вы использовали JavaScript для управления битами форматирования или настройки обработки событий при загрузке документа, вам необходимо прикрепить эту постобработку, которая будет запускаться после вызова AJAX.)
На самом деле вы не получили точного представления о типах вещей, которые вы пытаетесь заменить здесь, и моя первоначальная реакция такова: если одно событие запускает одновременное обновление нескольких разделов страницы, это признак того, что, возможно, вам следует объединять эти разделы в единый дисплей.
Сколько форматирования выполняется на стороне сервера по сравнению с тем, сколько делается на стороне клиента с помощью JavaScript? Я бы сказал, что форматирование на стороне сервера, если возможно, так у вас будет код, отражающий обсуждения, которые вы обсуждали по поводу макета и логики отображения. Форматирование на стороне клиента может использоваться для решения других проблем, связанных с интерфейсом - сортировка строк в таблице и чередование цветов строк с помощью селекторов: odd и: even, отображение и скрытие блоков div для создания «отображения с вкладками» без обращения к серверу, поскольку данные выиграли не меняются просто от выбора новой вкладки и тому подобного.
Наконец, AJAX односторонний. Если ваша веб-страница представляет собой представление базы данных, это не такая уж большая проблема, но использование AJAX-манипуляций вместо обычной навигации - ужасная идея.
Ваш пример новостей - это именно то, что я собираюсь сделать. Мой вопрос в том, действительно ли это считается хорошей практикой?
Более того, если вы следовали передовой практике, вы можете делать то же самое (отображать новости) таким же образом. Если вы смешали логику для подсчета «самых просматриваемых новостей» при обработке, так что обновление всего раздела новостей создает проблемы, такое смешивание не является хорошей практикой.
Я думаю, что наиболее важным требованием является требование обновления. Если после нескольких обновлений AJAX я нажимаю кнопку «Обновить», то страница, на которую я только что смотрел, должна быть страницей, которая появляется. Если по какой-либо причине страница возвращается в предыдущее состояние, это значит, что URL-адрес неверен. Если по какой-либо причине ваши данные AJAX сделают URL-адрес в браузере недействительным, вам не следует использовать AJAX для получения этих данных.
Есть исключения, конечно, для данных это даже новее, чем последний запрос AJAX. Но, очевидно, я не об этом. Экран живого чата может получать обновления между последним запросом AJAX и обновлением. Ничего страшного. Я говорю о логическом содержании и описывающем его URL-адресе, который всегда должен быть синхронизирован.
Если бы вы обычно заменяли все содержимое страницы с помощью вызовов AJAX, я бы согласился, что у вас возникла проблема. Однако мне кажется, что вы пытаетесь тщательно продумать последствия своего дизайна и пытаетесь, где это возможно, избежать того, что аннаката назвала «антипаттерном AJAX».
Мое правило немного проще: до тех пор, пока на странице остается значительный объем контекста (например, меню слева, заголовок, различные элементы управления, заголовок страницы и т. д.), Я могу заменить почти что-либо с помощью вызова AJAX. При этом я никогда не боролся со страницей, на которой было бы столько кода, сгенерированного AJAX, как у вас.
Однако у меня есть один вопрос: нельзя ли закодировать состояние, чтобы вы могли просто заменить некоторые из Div в своем примере, а не все? Если нет, думали ли вы об этом?
Да, замена блоков по отдельности происходит непосредственно перед заменой их всех одновременно. Это, безусловно, вариант, и он хорош до тех пор, пока не возникнет необходимость определить, что в список нужно добавить новые div.
Мне очень интересно услышать ответы на этот вопрос. Я боролся с теми же проблемами в недавнем проекте и столкнулся с некоторыми проблемами. Когда я заметил, что дублирую логику отображения в файлах js, я изменил их на частичную отрисовку страниц. То, что у меня получилось, было довольно запутанным.