Войти
A одностраничное приложение (SPA ) - это веб-приложение или веб-сайт, который взаимодействует с пользователем путем динамической перезаписи текущей веб-страницы новыми данными с веб-сервера вместо метода загрузки браузера по умолчанию целые новые страницы. Цель - более быстрые переходы, которые сделают веб-сайт более похожим на собственное приложение.
В SPA все необходимые HTML, JavaScript и Код CSS либо извлекается браузером при загрузке одной страницы, либо соответствующие ресурсы динамически загружаются и добавляются на страницу по мере необходимости, обычно в ответ на действия пользователя. Страница не перезагружается ни на каком этапе процесса и не передает управление другой странице, хотя хэш местоположения или API истории HTML5 можно использовать для обеспечения восприятия и навигации по отдельным логическим страницам в приложении.
Происхождение термина одностраничное приложение неясно, хотя концепция обсуждалась по крайней мере еще в 2003 году. Стюарт Моррис, студент-программист в Кардиффском университете, Уэльс, в апреле 2002 года написал автономный веб-сайт на slashdotslash.com с теми же целями и функциями, а позже в том же году Лукас Бирдо, Кевин Хакман, Майкл Пичи и Клиффорд Йе описали реализацию одностраничного приложения в патенте США 8136109.
JavaScript может использоваться в веб-браузере для отображения пользовательского интерфейса (UI), запустить логику приложения и связаться с веб-сервером. Доступны зрелые библиотеки с открытым исходным кодом, которые поддерживают создание SPA, что сокращает объем кода JavaScript, который приходится писать разработчикам.
Существуют различные доступные методы, позволяющие браузеру сохранять одну страницу, даже когда приложение требует связи с сервером.
Фреймворки и библиотеки JavaScript веб-браузера, такие как AngularJS, Ember.js, ExtJS, Knockout.js, Meteor.js, React, Vue.js и Svelte приняли принципы SPA. Помимо ExtJS, все они с открытым исходным кодом.
По состоянию на 2006 год наиболее известной используемой техникой был Ajax. Ajax включает использование асинхронных запросов к серверу для данных XML или JSON, например, с помощью JavaScript XMLHttpRequest или более современного fetch () (с 2017 г.), или устаревший объект ActiveX. В отличие от декларативного подхода большинства фреймворков SPA, с Ajax веб-сайт напрямую использует JavaScript или библиотеку JavaScript, такую как jQuery, для управления DOM и редактирования HTML. элементы. В дальнейшем Ajax получил распространение благодаря таким библиотекам, как jQuery, которые обеспечивают более простой синтаксис и нормализуют поведение Ajax в разных браузерах, которые исторически имели разное поведение.
WebSockets - это технология двунаправленной связи клиент-сервер в реальном времени, которая является частью спецификации HTML5. Для связи в реальном времени их использование превосходит Ajax с точки зрения производительности и простоты.
События, отправленные сервером (SSE) - это метод, с помощью которого серверы могут инициировать передачу данных клиентам браузера. После того, как начальное соединение установлено, поток событий остается открытым, пока не будет закрыт клиентом. SSE отправляются по традиционному протоколу HTTP и имеют множество функций, которые отсутствуют в WebSockets по своей конструкции, такие как автоматическое переподключение, идентификаторы событий и возможность отправки произвольных событий.
Хотя этот метод устарело, асинхронные вызовы к серверу также могут быть выполнены с использованием технологий подключаемых модулей браузера, таких как Silverlight, Flash или Java-апплеты.
Запросы к серверу обычно приводят либо к необработанным данным (например, XML или JSON ), либо к новому HTML. вернулся. В случае, когда сервер возвращает HTML, JavaScript на клиенте обновляет частичную область DOM (Document Object Model ). Когда возвращаются необработанные данные, часто для перевода используется клиентский процесс JavaScript XML / (XSL ) (а в случае JSON - шаблон ). необработанные данные в HTML, который затем используется для обновления частичной области DOM.
SPA перемещает логику с сервера на клиент, при этом роль веб-сервера превращается в API чистых данных или веб-службу. Этот архитектурный сдвиг в некоторых кругах был назван «архитектурой тонкого сервера», чтобы подчеркнуть, что сложность была перенесена с сервера на клиент, с аргументом, что это в конечном итоге снижает общую сложность системы.
Сервер сохраняет необходимое состояние в памяти состояния клиента страницы. Таким образом, когда любой запрос попадает на сервер (обычно это действия пользователя), сервер отправляет соответствующий HTML и / или JavaScript с конкретными изменениями, чтобы привести клиента в новое желаемое состояние (обычно добавление / удаление / обновление части клиентский DOM). В то же время состояние на сервере обновляется. Большая часть логики выполняется на сервере, и HTML обычно также отображается на сервере. В некотором смысле сервер имитирует веб-браузер, получая события и выполняя дельта-изменения в состоянии сервера, которые автоматически передаются клиенту.
Для этого подхода требуется больше памяти сервера и серверной обработки, но преимуществом является упрощенная модель разработки, поскольку а) приложение обычно полностью кодируется на сервере, и б) данные и состояние пользовательского интерфейса на сервере совместно используются то же пространство памяти без необходимости настраивать мосты связи клиент / сервер.
Это вариант подхода к серверу с отслеживанием состояния. Клиентская страница отправляет данные, представляющие ее текущее состояние, на сервер, обычно через запросы Ajax. Используя эти данные, сервер может восстановить состояние клиента той части страницы, которую необходимо изменить, и может сгенерировать необходимые данные или код (например, в формате JSON или JavaScript), который возвращается клиенту для получения его в новое состояние, обычно изменяя дерево DOM страницы в соответствии с действием клиента, которое мотивировало запрос.
Этот подход требует, чтобы на сервер было отправлено больше данных, и может потребоваться больше вычислительных ресурсов на запрос для частичного или полного восстановления состояния клиентской страницы на сервере. В то же время этот подход легче масштабировать, поскольку на сервере нет данных о странице для каждого клиента, и, следовательно, запросы Ajax могут быть отправлены на разные серверные узлы без необходимости совместного использования данных сеанса или привязки к серверу.
Некоторые SPA могут выполняться из локального файла с использованием схемы URI файла. Это дает пользователям возможность загружать SPA с сервера и запускать файл с локального запоминающего устройства, независимо от возможности подключения к серверу. Если такой SPA хочет хранить и обновлять данные, он должен использовать веб-хранилище на основе браузера. Эти приложения извлекают выгоду из достижений, доступных с HTML5.
Поскольку SPA представляет собой эволюцию от модели перерисовки страниц без сохранения состояния, для которой изначально были разработаны браузеры, возникают некоторые новые проблемы. появился. Возможные решения (различной сложности, полноты и авторского контроля) включают:
Из-за отсутствия выполнения JavaScript на сканерах некоторых популярных поисковых систем, SEO ( Поисковая оптимизация ) исторически представляла проблему для общедоступных веб-сайтов, желающих принять модель SPA.
В период с 2009 по 2015 год Центр веб-мастеров Google предлагал, а затем рекомендовал «Схема сканирования AJAX» с использованием начального восклицательного знака в идентификаторах фрагментов для страниц с отслеживанием состояния AJAX (#!). На сайте SPA должно быть реализовано специальное поведение, чтобы сканер поисковой системы мог извлекать соответствующие метаданные. Для поисковых систем, которые не поддерживают эту схему хеширования URL-адресов, хешированные URL-адреса SPA остаются невидимыми. Эти «хэш-бэнг» URI считались проблемными рядом авторов, включая Джени Теннисон из W3C, потому что они делают страницы недоступными для тех, у кого в браузере не активирован JavaScript. Они также нарушают заголовки HTTP referer, поскольку браузерам не разрешено отправлять идентификатор фрагмента в заголовке Referer. В 2015 году Google отказался от своего предложения по сканированию Hash-bang AJAX.
В качестве альтернативы приложения могут отображать загрузку первой страницы на сервере и последующие обновления страниц на клиенте. Это традиционно сложно, потому что код рендеринга может быть написан на другом языке или на другом языке на сервере и на клиенте. Использование шаблонов без логики, кросс-компиляция с одного языка на другой или использование одного и того же языка на сервере и клиенте может помочь увеличить объем кода, который можно совместно использовать.
Поскольку SEO-совместимость в SPA нетривиальна, стоит отметить, что SPA обычно не используются в контексте, когда индексирование поисковой системой является обязательным или желательным. Примеры использования включают приложения, которые отображают личные данные, скрытые за системой аутентификации. В тех случаях, когда эти приложения являются потребительскими продуктами, часто для целевой страницы приложений и маркетингового сайта используется классическая модель «перерисовки страницы», которая предоставляет достаточно метаданных для того, чтобы приложение появилось в качестве попадания в поисковом запросе. Блоги, форумы поддержки и другие традиционные артефакты перерисовки страниц часто располагаются вокруг SPA, которые могут заполнять поисковые системы соответствующими терминами.
Другой подход, используемый серверно-ориентированными веб-фреймворками, такими как Java-based ItsNat, заключается в визуализации любого гипертекста на сервере с использованием того же языка и технологии шаблонов. При таком подходе сервер точно знает состояние DOM на клиенте, любое необходимое обновление большой или малой страницы генерируется на сервере и передается Ajax, точный код JavaScript для перевода клиентской страницы в новое состояние, выполняя методы DOM.. Разработчики могут решить, какие состояния страницы должны сканироваться веб-пауками для SEO, и иметь возможность генерировать необходимое состояние во время загрузки, генерируя простой HTML вместо JavaScript. В случае инфраструктуры ItsNat это происходит автоматически, потому что ItsNat хранит дерево DOM клиента на сервере как дерево DOM Java W3C; рендеринг этого дерева DOM на сервере генерирует простой HTML во время загрузки и действия DOM JavaScript для запросов Ajax. Эта двойственность очень важна для SEO, потому что разработчики могут создавать с одним и тем же кодом Java и чистым шаблоном на основе HTML, создавая желаемое состояние DOM на сервере; во время загрузки страницы ItsNat генерирует обычный HTML, что делает это состояние DOM SEO-совместимым.
Начиная с версии 1.3 ItsNat предоставляет новый режим без сохранения состояния, и клиентская DOM не хранится на сервере, потому что с клиентом в режиме без сохранения состояния состояние DOM частично или полностью восстанавливается на сервере при обработке любого Ajax. запрос на основе требуемых данных, отправленных клиентом, информирующий сервер о текущем состоянии DOM; режим без сохранения состояния может быть также совместим с SEO, поскольку совместимость с SEO происходит во время загрузки начальной страницы, на которую не влияют режимы с сохранением состояния или без него. Другой возможный выбор - такие фреймворки, как PreRender, Puppeteer, Rendertron, которые можно легко интегрировать в любой веб-сайт в качестве промежуточного программного обеспечения с конфигурацией веб-сервера, позволяющей обрабатывать запросы ботов (бот Google и другие) промежуточным программным обеспечением, в то время как запросы, не относящиеся к ботам, обслуживаются как обычно. Эти фреймворки периодически кэшируют соответствующие страницы веб-сайтов, чтобы последние версии были доступны поисковым системам. Эти фреймворки были официально одобрены Google.
Есть несколько обходных путей, которые позволяют сделать вид, что веб-сайт доступен для сканирования. Оба включают создание отдельных HTML-страниц, которые отражают содержимое SPA. Сервер может создать версию сайта на основе HTML и доставить ее поисковым роботам, или можно использовать автономный браузер, такой как PhantomJS, для запуска приложения JavaScript и вывода полученного HTML.
И то, и другое требует значительных усилий и в конечном итоге может вызвать головную боль при обслуживании больших сложных сайтов. Есть также потенциальные подводные камни SEO. Если HTML-код, сгенерированный сервером, будет слишком отличаться от содержимого SPA, сайт будет оштрафован. Запуск PhantomJS для вывода HTML может снизить скорость отклика страниц, для чего поисковые системы, в частности Google, понижают рейтинг.
Один Способ увеличения объема кода, который может совместно использоваться между серверами и клиентами, заключается в использовании языка шаблонов без логики, такого как Mustache или Handlebars. Такие шаблоны могут отображаться на разных языках хоста, например, Ruby на сервере и JavaScript на клиенте. Однако простое совместное использование шаблонов обычно требует дублирования бизнес-логики, используемой для выбора правильных шаблонов и заполнения их данными. Отрисовка из шаблонов может иметь отрицательное влияние на производительность при обновлении только небольшой части страницы, например значения вводимого текста в большом шаблоне. Замена всего шаблона также может нарушить выбор пользователя или положение курсора, тогда как обновление только измененного значения может не измениться. Чтобы избежать этих проблем, приложения могут использовать привязки данных пользовательского интерфейса или детализированные манипуляции DOM для обновления только соответствующих частей страницы вместо повторной визуализации целых шаблонов.
Поскольку SPA по определению является «отдельной страницей», модель нарушает дизайн браузера для навигации по истории страниц с использованием кнопок «вперед» или «назад». Это представляет собой препятствие для удобства использования, когда пользователь нажимает кнопку «Назад», ожидая предыдущего состояния экрана в SPA, но вместо этого выгружается отдельная страница приложения и отображается предыдущая страница в истории браузера.
Традиционным решением для SPA было изменение хэша идентификатора фрагмента URL-адреса браузера в соответствии с текущим состоянием экрана. Это может быть достигнуто с помощью JavaScript и вызывает создание событий истории URL в браузере. Пока SPA способен восстанавливать то же состояние экрана из информации, содержащейся в хэше URL-адреса, ожидаемое поведение кнопки возврата сохраняется.
Для дальнейшего решения этой проблемы в спецификации HTML5 введены pushState и replaceState, обеспечивающие программный доступ к фактическому URL-адресу и истории браузера.
Инструменты аналитики, такие как Google Analytics, в значительной степени полагаются на загрузку целых новых страниц в браузере, инициированную загрузкой новой страницы. СПА так не работают.
После загрузки первой страницы все последующие изменения страниц и содержимого обрабатываются внутренним приложением, которое должно просто вызвать функцию для обновления пакета аналитики. Без вызова указанной функции браузер никогда не запускает новую загрузку страницы, ничего не добавляется в историю браузера, а пакет аналитики не знает, кто что делает на сайте.
Можно добавлять события загрузки страницы в SPA с помощью API истории HTML5; это поможет интегрировать аналитику. Сложность заключается в том, чтобы справиться с этим и обеспечить точное отслеживание всего - это включает в себя проверку отсутствующих отчетов и двойных записей. Некоторые платформы обеспечивают интеграцию аналитики с открытым исходным кодом для большинства основных поставщиков аналитики. Разработчики могут интегрировать их в приложение и убедиться, что все работает правильно, но нет необходимости делать все с нуля.
У одностраничных приложений медленнее загрузка первой страницы по сравнению с серверными приложениями. Это связано с тем, что первая загрузка должна привести к отключению платформы и кода приложения перед рендерингом требуемого представления в виде HTML в браузере. Серверное приложение просто должно отправить в браузер необходимый HTML-код, уменьшая задержку и время загрузки.
Есть несколько способов ускорить начальную загрузку SPA, например, усиленный подход к кэшированию и отложенную загрузку модулей при необходимости. Но невозможно уйти от того факта, что ему необходимо загрузить фреймворк, по крайней мере, часть кода приложения, и, скорее всего, он будет обращаться к API для данных перед отображением чего-либо в браузере. Это компромиссный сценарий «заплати мне сейчас или заплати позже». Вопрос производительности и времени ожидания остается решением, которое должен принять разработчик.
SPA полностью загружается при начальной загрузке страницы, а затем области страницы заменяются или обновляются новыми фрагментами страницы, загружаемыми с сервера по запросу. Чтобы избежать чрезмерной загрузки неиспользуемых функций, SPA часто будет постепенно загружать дополнительные функции по мере необходимости, либо небольшие фрагменты страницы, либо полные модули экрана.
Таким образом, существует аналогия между «состояниями» в SPA и «страницами» на традиционном веб-сайте. Поскольку «навигация по состояниям» на той же странице аналогична навигации по страницам, теоретически любой страничный веб-сайт может быть преобразован в одностраничный, заменяя на той же странице только измененные части.
Подход SPA в Интернете похож на метод представления однодокументного интерфейса (SDI), популярный в нативных настольных приложениях.
