Динамическое обновление веб-страницы

Динамическое обновление веб-страницы

225
ПОДЕЛИТЬСЯ

Введение
Кто должен генерировать новейший html — сервер либо javascript? Никого уже не удивишь концепцией динамического HTML, практически все веб-сайты издавна в той либо другой мере употребляют javascript для того , чтоб сделать странички интерактивными. Но как конкретно обновлять структуру странички? А может, все совместно? А с возникновением технологии AJAX стало вероятным асинхронно генерировать запросы к серверу, чтоб изменять старенькые данные на сервере либо получать новейшие.

Поглядим, как можно ответить на эти вопросцы.

Сходу скажу, что я не собираюсь обрисовывать этот процесс конкретно, тут требуется лишь осознание основной логики процесса. Для начала, я обрисую жизненный цикл странички.

Хоть какое интернет-приложение можно логически поделить на две составляющие — на клиентскую часть и серверную часть. К клиентской части относятся сам браузер и скрипты, которые он выполняет, к серверной — набор скриптов, которые генерируют ответ на хоть какой запрос юзера.

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

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

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

Поближе к сущности
Мы желаем, чтоб браузер часто инспектировал обновления ленты, добавляя анонсы по мере их возникновения. Для удобства разъяснения разглядим вариант обновления обычный странички с лентой новостей и, скажем, счетчиком подписчиков. А еще мы желаем, чтоб каждый гость лицезрел динамику роста популярности нашего веб-сайта — пусть счетчик подписчиков тоже часто обновляется.

Тело нашей странички может смотреться, к примеру, так:

<span id="subscr_cnt">Подписчиков: 42</span>
<ul id="news">
<li><a href="/australia">Наикрупнейшие на Земле метеоритные кратеры случаем отыскали в Австралии</a></li>
<li><a href="/wonderwoman">Волшебство-дама ответила на критику о собственной груди</a></li>
<li><a href="/romeo_madness">«Ромео и Джульетту» экранизируют в духе «300 спартанцев»</a></li>
</ul>
Вариант 1 — дублирование
Основная мысль — логику отображения знает и клиентская, и серверная часть. В таком случае, ответы на постоянные запросы со стороны клиента могут содержать только данные — конфигурации в модели, и смотреться, к примеру, так:

{
subscr_cnt: 44,
news:[
{
href: "/wiskey",
name: "Названы фаворитные в мире сорта виски 2015 года"
},
{
href: "/kindergarden",
name: "В Нью-Йорке возник детский сад для взрослых"
}
]
}
При получении такового ответа клиентская часть «оборачивает» данные в html-теги, добавляет нужные тексты и обновляет структуру странички.

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

Плюсы подхода:

Малый размер трафика — передаются лишь нужные данные;

Минусы подхода:

Требуется продублировать код — он будет и в клиентской части, и в серверной;
Клиентская часть обязана знать, как конкретно поступать с каждой порцией данных от сервера — время от времени необходимо заменить html элемента, время от времени добавить новейшие данные к уже существующему коду;

Вариант 2 — всевластный сервер и «толстые» ответы
Тут ответ сервера смотрится так: Основная мысль — логику отображения знает лишь сервер, клиентская часть получает уже готовый html-код частей.

{
subscr_cnt: "Подписчиков: 44",
news: "<li><a href="/australia">Наикрупнейшие на Земле метеоритные кратеры случаем отыскали в Австралии</a></li> n <li><a href="/wonderwoman">Волшебство-дама ответила на критику о собственной груди</a></li> <li><a href="/romeo_madness">«Ромео и Джульетту» экранизируют в духе «300 спартанцев»</a></li> <li><a href="/wiskey">Названы фаворитные в мире сорта виски 2015 года</a></li> <li><a href="/kindergarden">В Нью-Йорке возник детский сад для взрослых</a></li>"
}
Реализуется же таковой метод просто — сервер генерирует страничку по кусочкам, клиент при получении ответа подменяет тела отдельных частей. Замечу, что пересылается тут весь html каждого компонента на страничке.

Плюсы подхода:

Простота реализации;
Отсутствие дублирования кода;

Минусы подхода:

Многократная генерация 1-го и того же кода, в особенности неэффективно при маленьких конфигурациях;
Большой размер трафика, в особенности на огромных страничках;

Вариант 2а — всевластный сервер и «тонкие» ответы
Наш ответ тогда может стать таковым: Сервер может не отправлять весь html компонента, а присылать лишь «дельту» — конфигурации, которые нужно внести. Можно попробовать поправить основной недочет предшествующего варианта.

{
subscr_cnt: {
html: "Подписчиков: 44",
mode: "replace"
},
news: {
html: "<li><a href="/wiskey">Названы фаворитные в мире сорта виски 2015 года</a></li> <li><a href="/kindergarden">В Нью-Йорке возник детский сад для взрослых</a></li>",
mode: "append"
}
}
Сейчас клиент описывает элемент, который будет изменять, и то, как он его будет изменять, конкретно из ответа сервера.

Плюсы подхода:

Отсутствие дублирования кода;

Минусы подхода:

Все еще довольно большой размер сетевого трафика;
Клиент должен выслать серверу текущее состояние каждой составляющие, закодированное неким образом, чтоб сервер сообразил, относительно чего же считать дельту;
Сложность вычисления и записи дельты в случае нетривиальных конфигураций;
Общее усложнение и клиентской, и серверной части;

Вариант 3 — всевластный javascript
В таком случае сервер будет лишь предоставлять данные, нужные для отображения. Ответы, как и в первом варианте, будут содержать лишь данные: Можно переложить всю ответственность за генерацию html на клиента.

{
subscr_cnt: 44,
news:[
{
href: "/wiskey",
name: "Названы фаворитные в мире сорта виски 2015 года"
},
{
href: "/kindergarden",
name: "В Нью-Йорке возник детский сад для взрослых"
}
]
}
А заключается оно в том, что сервер не выполняет первоначальную генерацию странички, её сборка осуществляется уже браузером клиента. Вариант этот лишь смотрится странноватым, он может понадобиться, раз нужно уменьшить нагрузку на сервер. Так в чем же существенное отличие от первого варианта?

Плюсы подхода:

Малый размер трафика — передаются лишь нужные данные;
Уменьшение перегрузки на сервер;

Минусы подхода:

Высочайшая перегрузка на комп юзера;
Возможна избыточность — часть познаний клиентской части о отображении может так и остаться невостребованной, раз какие-то действия не наступят;

Заключение
Лично я во встреченных мною проектах почаще всего лицезрел 1-ый вариант, невзирая на нарушение им моего возлюбленного принципа DRY — Don`t repeat yourself. Каждый из рассмотренных способов имеет право на жизнь, и может быть применен в проектах разной трудности.

А какие принципы вы используете при разработке динамических страничек? habrahabr.ru

НЕТ КОММЕНТАРИЕВ

ОСТАВЬТЕ ОТВЕТ

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.