Одностраничное приложение

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

В SPA обновление страницы никогда не происходит; вместо этого весь необходимый код HTML , JavaScript и CSS либо извлекается браузером при одной загрузке страницы, или соответствующие ресурсы динамически загружаются и добавляются на страницу по мере необходимости, обычно в ответ на действия пользователя.

История

Происхождение термина «одностраничное приложение» неясно, хотя эта концепция обсуждалась по крайней мере еще в 2003 году технологическими евангелистами из Netscape. Стюарт Моррис, студент-программист Кардиффского университета в Уэльсе, в апреле 2002 года написал автономный веб-сайт slashdotslash.com с теми же целями и функциями: а позже в том же году Лукас Бирдо, Кевин Хэкман, Майкл Пичи и Клиффорд Йе описали реализацию одностраничного приложения в патенте США № 8,136,109. Более ранние формы назывались богатыми веб-приложениями .

JavaScript можно использовать в веб-браузере для отображения пользовательского интерфейса (UI), выполнения логики приложения и взаимодействия с веб-сервером. Доступны зрелые бесплатные библиотеки, которые поддерживают создание SPA, сокращая объем кода JavaScript, который приходится писать разработчикам.

Технические подходы

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

Хэши документов

Авторы HTML могут использовать идентификаторы элементов для отображения или скрытия различных разделов HTML-документа. Затем, используя CSS, авторы могут использовать :target селектор псевдокласса, чтобы показывать только тот раздел страницы, к которому перешел браузер.

JavaScript-фреймворки

Фреймворки и библиотеки JavaScript веб-браузера, такие как AngularJS , Ember.js , ExtJS , Knockout.js , Meteor.js , React , Vue.js и Svelte , приняли принципы SPA. За исключением ExtJS, все они бесплатны.

• AngularJS — это полностью клиентская среда. Шаблоны AngularJS основаны на двунаправленной привязке данных пользовательского интерфейса . Привязка данных — это автоматический способ обновления представления при каждом изменении модели, а также обновления модели при изменении представления. HTML-шаблон компилируется в браузере. На этапе компиляции создается чистый HTML, который браузер повторно отображает в режиме реального времени. Этот шаг повторяется для последующих просмотров страниц. В традиционном серверном программировании HTML такие понятия, как контроллер и модель, взаимодействуют внутри серверного процесса для создания новых представлений HTML. В среде AngularJS состояния контроллера и модели сохраняются в клиентском браузере. Таким образом, новые страницы могут создаваться без какого-либо взаимодействия с сервером.
• Angular 2+ — это SPA Framework, разработанный Google после AngularJS. Он на несколько шагов опережает Angular, и существует сильное сообщество разработчиков, использующих этот фреймворк. Структура обновляется дважды в год. Текущая версия — Angular 18.0.3 (по состоянию на июнь 2024 г.). ), и в эту среду часто добавляются новые функции и исправления.
• Ember.js — это клиентская среда веб-приложений JavaScript, основанная на архитектурном шаблоне программного обеспечения модель-представление-контроллер (MVC). Он позволяет разработчикам создавать масштабируемые одностраничные приложения путем включения общих идиом и лучших практик в структуру, которая обеспечивает богатую объектную модель, декларативную двустороннюю привязку данных, вычисляемые свойства, автоматическое обновление шаблонов на базе Handlebars.js и маршрутизатор для управление состоянием приложения.
• ExtJS также является клиентской платформой, позволяющей создавать приложения MVC. Он имеет собственную систему событий, управление окнами и макетами, управление состоянием (хранилищами) и различные компоненты пользовательского интерфейса (сетки, диалоговые окна, элементы форм и т. д.). Он имеет собственную систему классов с динамическим или статическим загрузчиком. Приложение, созданное с помощью ExtJS, может существовать либо само по себе (с состоянием в браузере), либо на сервере (например, с REST API, который используется для заполнения его внутренних хранилищ). В ExtJS встроены только возможности использования localStorage, поэтому более крупным приложениям нужен сервер для хранения состояния.
• Knockout.js — это клиентская платформа, использующая шаблоны на основе шаблона Model-View-ViewModel .
• Meteor.js — это полнофункциональная (клиент-серверная) среда JavaScript, разработанная исключительно для SPA. Он имеет более простую привязку данных, чем Angular, Ember или ReactJS. и использует протокол распределенных данных и шаблон публикации-подписки для автоматического распространения изменений данных среди клиентов в режиме реального времени, не требуя от разработчика написания какого-либо кода синхронизации. Полная реактивность стека гарантирует, что все уровни, от базы данных до шаблонов, автоматически обновляются при необходимости. Экосистемные пакеты, такие как рендеринг на стороне сервера. решить проблему поисковой оптимизации.
• React — это библиотека JavaScript для создания пользовательских интерфейсов . Его поддерживают Facebook , Instagram и сообщество отдельных разработчиков и корпораций. React использует расширение синтаксиса для JavaScript под названием JSX , которое представляет собой смесь JS и HTML (подмножество HTML). Некоторые компании используют React с Redux (библиотека JavaScript) , которая добавляет возможности управления состоянием, что (вместе с несколькими другими библиотеками) позволяет разработчикам создавать сложные приложения.
• Vue.js — это JavaScript-фреймворк для создания пользовательских интерфейсов. Разработчики Vue также предоставляют Pinia для управления состоянием.
• Svelte — это платформа для создания пользовательских интерфейсов, которая компилирует код Svelte в JavaScript DOM (объектная модель документа), что позволяет избежать необходимости связывать платформу с клиентом и позволяет упростить синтаксис разработки приложений.

Аякс

По состоянию на 2006 год наиболее известной используемой техникой был Ajax . Ajax предполагает использование асинхронных запросов к серверу для данных XML или JSON , например, с помощью JavaScript XMLHttpRequest или более современных fetch() (с 2017 г.) или устаревший объект ActiveX . В отличие от декларативного подхода большинства SPA-фреймворков, при использовании Ajax веб-сайт напрямую использует JavaScript или библиотеку JavaScript, такую ​​как jQuery, для управления DOM и редактирования элементов HTML. Ajax также популяризировался такими библиотеками, как jQuery , которые обеспечивают более простой синтаксис и нормализуют поведение Ajax в разных браузерах, которые исторически имели разное поведение.

Вебсокеты

WebSockets — это технология двунаправленной связи клиент-сервер в реальном времени, которая является частью спецификации HTML. Для общения в реальном времени их использование превосходит Ajax по производительности. и простота.

События, отправленные сервером

События, отправленные сервером (SSE), — это метод, с помощью которого серверы могут инициировать передачу данных клиентам браузера. После установления первоначального соединения поток событий остается открытым до тех пор, пока не будет закрыт клиентом. SSE отправляются по традиционному HTTP и имеют множество функций, которых нет в WebSockets по своей конструкции, таких как автоматическое переподключение, идентификаторы событий и возможность отправлять произвольные события.

Плагины для браузера

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

Транспортировка данных (XML, JSON и Ajax)

Запросы к серверу обычно приводят либо к необработанным данным (например, XML или JSON ), либо нового HTML к возврату . В случае, когда сервер возвращает HTML, JavaScript на клиенте обновляет частичную область DOM ( объектная модель документа ). Когда возвращаются необработанные данные, часто на стороне клиента используется процесс JavaScript XML /( XSL ) (а в случае JSON — шаблон ) для перевода необработанных данных в HTML, который затем используется для обновления частичной области DOM. .

Серверная архитектура

Тонкая серверная архитектура

SPA переносит логику с сервера на клиент, при этом роль веб-сервера превращается в чистый API данных или веб-сервис. Этот архитектурный сдвиг в некоторых кругах был назван «архитектурой тонкого сервера», чтобы подчеркнуть, что сложность была перенесена с сервера на клиент, с аргументом, что это в конечном итоге снижает общую сложность системы.

Толстая серверная архитектура с сохранением состояния

Сервер сохраняет необходимое состояние в памяти клиентского состояния страницы. Таким образом, когда на сервер поступает какой-либо запрос (обычно действия пользователя), сервер отправляет соответствующий HTML и/или JavaScript с конкретными изменениями, чтобы привести клиента в новое желаемое состояние (обычно добавление/удаление/обновление части клиентский DOM). В то же время состояние на сервере обновляется. Большая часть логики выполняется на сервере, и HTML обычно также отображается на сервере. В некотором смысле сервер имитирует веб-браузер, получая события и выполняя дельта-изменения в состоянии сервера, которые автоматически передаются клиенту.

Этот подход требует больше серверной памяти и серверной обработки, но преимуществом является упрощенная модель разработки, поскольку а) приложение обычно полностью закодировано на сервере и б) данные и состояние пользовательского интерфейса на сервере совместно используются в одном и том же пространстве памяти без каких-либо ограничений. необходимость создания пользовательских мостов связи клиент/сервер.

Толстая серверная архитектура без сохранения состояния

Это вариант подхода сервера с отслеживанием состояния. Клиентская страница отправляет данные, представляющие ее текущее состояние, на сервер, обычно через запросы Ajax. Используя эти данные, сервер может реконструировать состояние клиента той части страницы, которую необходимо изменить, и может сгенерировать необходимые данные или код (например, в формате JSON или JavaScript), который возвращается клиенту для его в новое состояние, обычно изменяя дерево DOM страницы в соответствии с действием клиента, которое послужило причиной запроса.

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

Запуск локально

Некоторые SPA могут выполняться из локального файла с использованием схемы URI файла . Это дает пользователям возможность загружать SPA с сервера и запускать файл с локального устройства хранения данных независимо от подключения к серверу. Если такой SPA хочет хранить и обновлять данные, он должен использовать веб-хранилище на базе браузера . Эти приложения извлекают выгоду из достижений HTML .

Проблемы с моделью SPA

Поскольку SPA представляет собой эволюцию модели перерисовки страниц без сохранения состояния, для которой изначально были разработаны браузеры, возникли некоторые новые проблемы. Возможные решения (разной сложности, полноты и авторского контроля):

• клиентские библиотеки JavaScript
• серверные веб-фреймворки, специализирующиеся на модели SPA
• эволюция браузеров и спецификации HTML, разработан для модели SPA

Поисковая оптимизация

Из-за отсутствия выполнения JavaScript сканерами некоторых популярных поисковых систем в Интернете , SEO ( поисковая оптимизация ) исторически представляло проблему для общедоступных веб-сайтов, желающих принять модель SPA.

В период с 2009 по 2015 год Центр веб-мастеров Google предложил, а затем рекомендовал «схему сканирования AJAX». использование начального восклицательного знака в идентификаторах фрагментов для страниц AJAX с отслеживанием состояния ( #!). На сайте SPA должно быть реализовано специальное поведение, позволяющее извлекать соответствующие метаданные сканеру поисковой системы. Для поисковых систем, которые не поддерживают эту схему хеширования URL-адресов , хешированные URL-адреса SPA остаются невидимыми. Ряд авторов, в том числе Джени Теннисон из W3C, сочли эти «хэш-взрывные» URI проблематичными, поскольку они делают страницы недоступными для тех, у кого JavaScript в браузере не активирован . Они также нарушают заголовки HTTP-реферера , поскольку браузерам не разрешено отправлять идентификатор фрагмента в заголовке Referer. В 2015 году Google отказался от своего хеш-предложения по сканированию AJAX.

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

В 2018 году Google представил динамический рендеринг как еще один вариант для сайтов, желающих предложить сканерам тяжелую версию страницы без JavaScript для целей индексирования. Динамический рендеринг переключается между версией страницы, отображаемой на стороне клиента, и предварительно обработанной версией для определенных пользовательских агентов. Этот подход предполагает, что ваш веб-сервер обнаруживает сканеры (через пользовательский агент) и направляет их к средству рендеринга, откуда им затем предоставляется более простая версия HTML-контента. С 2024 года Google больше не рекомендует динамический рендеринг. , предлагая вместо этого « рендеринг на стороне сервера , статический рендеринг или гидратацию ».

Поскольку совместимость с SEO не является тривиальной для SPA, стоит отметить, что SPA обычно не используются в контексте, где индексирование поисковыми системами является либо обязательным, либо желательным. Случаи использования включают приложения, которые раскрывают личные данные, скрытые за системой аутентификации . В тех случаях, когда эти приложения являются потребительскими продуктами, для целевой страницы приложения и маркетингового сайта часто используется классическая модель «перерисовки страницы», которая предоставляет достаточно метаданных, чтобы приложение отображалось как попадание в запрос поисковой системы. Блоги, форумы поддержки и другие традиционные артефакты перерисовки страниц часто располагаются вокруг SPA и могут наполнять поисковые системы соответствующими терминами.

Начиная с 2021 года и в частности с Google, совместимость с SEO для простого SPA проста и требует соблюдения всего нескольких простых условий.

Один из способов увеличить объем кода, который может совместно использоваться серверами и клиентами, — использовать язык шаблонов без логики, такой как Mustache или Handlebars . Такие шаблоны могут отображаться на разных хост-языках, например Ruby на сервере и JavaScript на клиенте. Однако простой обмен шаблонами обычно требует дублирования бизнес-логики, используемой для выбора правильных шаблонов и заполнения их данными. Визуализация из шаблонов может иметь отрицательные последствия для производительности при обновлении только небольшой части страницы — например, значения введенного текста в большом шаблоне. Замена всего шаблона также может нарушить выбор пользователя или положение курсора, тогда как обновление только измененного значения может не повлиять. Чтобы избежать этих проблем, приложения могут использовать привязки данных пользовательского интерфейса или детальные манипуляции с DOM , чтобы обновлять только соответствующие части страницы, а не перерисовывать целые шаблоны.

История браузера

Поскольку SPA по определению является «одной страницей», модель нарушает дизайн браузера для навигации по истории страниц с помощью кнопок «вперед» или «назад». Это представляет собой препятствие для удобства использования, когда пользователь нажимает кнопку «Назад», ожидая предыдущего состояния экрана в SPA, но вместо этого выгружается единственная страница приложения и отображается предыдущая страница в истории браузера.

Традиционным решением для SPA было изменение идентификатора хеш-фрагмента URL-адреса браузера в соответствии с текущим состоянием экрана. Этого можно достичь с помощью JavaScript, и события истории URL-адресов будут создаваться в браузере. Пока SPA способен восстанавливать то же состояние экрана на основе информации, содержащейся в хеше URL-адреса, ожидаемое поведение кнопки «Назад» сохраняется.

Для дальнейшего решения этой проблемы в спецификации HTML введены pushState и replaceState, обеспечивающие программный доступ к фактическому URL-адресу и истории браузера.

Аналитика

Инструменты аналитики, такие как Google Analytics, в значительной степени полагаются на загрузку целых новых страниц в браузере, инициируемую загрузкой новой страницы. СПА так не работают.

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

Сканирование безопасности

Подобно проблемам, с которыми сталкиваются сканеры поисковых систем, инструменты DAST могут столкнуться с трудностями при работе с этими приложениями, насыщенными JavaScript. Проблемы могут включать отсутствие гипертекстовых ссылок, проблемы с использованием памяти и ресурсы, загружаемые SPA, обычно доступные через интерфейс прикладного программирования или API. Одностраничные приложения по-прежнему подвержены тем же рискам безопасности, что и традиционные веб-страницы, такие как межсайтовый скриптинг (XSS) , но также и множеству других уникальных уязвимостей, таких как раскрытие данных через API, логика на стороне клиента и принудительное исполнение на стороне клиента. безопасности на стороне сервера. Чтобы эффективно сканировать одностраничное приложение, сканер DAST должен иметь возможность надежно и воспроизводимо перемещаться по клиентскому приложению, чтобы обеспечить обнаружение всех областей приложения и перехват всех запросов, которые приложение отправляет удаленным пользователям. серверы (например, запросы API).

Добавление загрузки страниц в SPA

В SPA можно добавлять события загрузки страницы с помощью API истории HTML; это поможет интегрировать аналитику. Трудность заключается в управлении этим и обеспечении точного отслеживания всего – это включает в себя проверку на отсутствие отсутствующих отчетов и двойных записей.Некоторые платформы предоставляют бесплатную интеграцию аналитики, подходящую большинству основных поставщиков аналитики. Разработчики могут интегрировать их в приложение и убедиться, что все работает корректно, но нет необходимости делать все с нуля.

Ускорение загрузки страницы

Существуют некоторые способы ускорения начальной загрузки SPA, такие как выборочная предварительная обработка целевой/индексной страницы SPA, кэширование и различные методы разделения кода, включая модули отложенной загрузки, когда это необходимо. Но уйти от того, что нужно скачать фреймворк, хотя бы часть кода приложения, не получится; и будет обращаться к API для данных, если страница динамическая. Это компромиссный сценарий «заплати мне сейчас или заплати мне позже». Вопрос производительности и времени ожидания остается решением, которое должен принять разработчик.

Жизненный цикл страницы

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

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

Подход SPA в Интернете аналогичен методу представления однодокументного интерфейса (SDI), популярному в собственных настольных приложениях.

См. также

• Прогрессивное веб-приложение (PWA)
• Серверные сценарии

Внешние ссылки

• Миграция многостраничных веб-приложений на одностраничные интерфейсы Ajax (Технологический университет Делфта)
• Манифест одностраничного интерфейса
• Динамический рендеринг