Статья опубликована в рамках: Научного журнала «Студенческий» № 19(63)
Рубрика журнала: Информационные технологии
Скачать книгу(-и): скачать журнал часть 1, скачать журнал часть 2, скачать журнал часть 3, скачать журнал часть 4
СПЕЦИФИКА РАЗРАБОТКИ РЕАКТИВНЫХ ВЕБ-ПРИЛОЖЕНИЙ НА ЯЗЫКЕ JAVASCRIPT
Реактивные подход к разработке веб-интерфейсов на сегодняшний день является самым распространенным и наиболее эффективным. Это во многом обусловлено его универсальностью и понятной методологией. Но с уложением разрабатываемого программного продукта, значительно усложняется и разработка, поэтому в данной статье описаны основные проблемы, с которыми программист может столкнуться и пути их решения.
Целью статьи является описание методологий разработки современных реактивных веб-приложений, технологий их реализации и нюансов работы с ними.
Стоит отметить, что в статье затрагиваются термины HTTP-запросов, поэтому читателю необходимо понимать их структуру.
Для начала стоит рассмотреть основные принципы реактивного программирования. В данной концепции среди данных, с которыми работает приложение, выделяется особая группа – состояния. Изменение состояний ведет к изменению структуры приложения. Эти изменения описываются разработчиком, но из конкретная реализация выполняется конкретной библиотекой.
Среди программных библиотек для построения реактивных веб-приложений стоит выделить: Angular, Vue, React, как наиболее распространенные.
Angular используется для построения крупных системы со сложной структурой.
В противовес Vue используется для небольших программ с конкретным функционалом.
React позволяет создавать как небольшие, так и средние программы.
Стоит отметить, что не только масштаб приложения определяет программную библиотеку ее реализации, с ростом сложности приложения, растет и сложность его создания, поэтому React не универсальный вариант, его синтаксис довольно тяжело воспринимать новичкам. Тем не менее, данная статья основана на опыте работы с библиотекой React.
Первая сложность, с которой столкнется каждый разработчик реактивных веб-приложений – управление состояниями. На рисунке 1 изображена схема обобщенного реактивного приложения.
Рисунок 1. Управление состояниями реактивного приложения
Здесь отображена еще одна концепция реактивных приложений – компонентный подход. Все приложение разбивается на функциональные блоки – компоненты. Каждый компонент имеет свои состояния. Управление состояниями, их передача от одного компонента к другому осуществляется следующим образом. Точка входа или же главный компонент может передавать свои данные и состояния сверху вниз своим потомкам, на рисунке это красные стрелки. Это сделано для обеспечения целостности и непротиворечивости состояний. Взаимодействия снизу вверх, то есть от потомка к родителю, осуществляются через обработку событий, на рисунке это зеленые стрелочки. Таким образом если в приложении вложенность компонентов n уровней, то подъем событий до точки входа будет осуществляться n-1 раз, что крайне неудобно и бесполезно.
Для решения данной проблемы была разработана методология Flux, которая позволяет выделить часть состояний в глобальное хранилище, которое будет доступно из любой точки приложения. Таким образом, если компоненту необходимо изменить состояние родителя на первом уровне иерархии, то есть состояние всего приложения, ему достаточно обратиться к глобальному хранилищу, а не поднимать события n-1 раз. Существует множество реализаций данной методологии, но наиболее распространены: Redux – для React и VueX – для Vue. Стоит отметить, что для сохранения целостности глобального хранилища состояний при их изменении используется подход ондонаправленного цикла, изображенного на рисунке 2.
Рисунок 2. Схема изменения глобальных состояний
Каждое изменение глобального хранилища заранее определено и называется Действие (Action). Действия обрабатываются Диспетчером (Dispatcher), так же заранее определенным образом. Происходит изменение Хранилища, которое вызывается изменения в Компоненте. Как видно из схемы все изменения определенны и не вызываются непредвиденных ситуаций.
Таким образом разрабатываются современные веб-интерфейсы, но веб-приложению необходимы данные, чтобы с ними работал пользователь. Получение данных – это отдельный слой разработки, который может быть реализован множеством способов, но в данной статье остановимся на работе приложения средствами клиентского JavaScript-приложения.
В языке JavaScript существует средство взаимодействия с внешними источниками данных – AJAX-запросы. Асинхронные запросы выглядят ультимативным способом сообщения приложения с источником данных, но это не так. Для клиентского языка существуют ограничения, связанные с кросс доменными запросами. Это означает, что если запрос отправляется по адресу, отличному от того, где располагается приложение, то для него действуют особые правила.
- если запрос простой, то на него не налагаются ограничения. К простым относятся GET и POST-запросы, а также используются только определенные заголовки запроса, определенные в [1].
- если запрос не относится к простым, то перед запросом будет отправлен еще один OPTION-запрос, содержащий заголовок origin, который содержит домен источника. Данный запрос должен ввернуть статус 200, иначе он будет заблокирован браузером.
Если по каким-то причинам приложение не может отправить простой запрос, например, данные в формате JSON или заголовок для авторизации, то существует несколько способов обхода этих ограничений.
- проксирование – это способ, при котором на конечной узле создается точка доступа, к которой можно послать простые запросы, а она в свою очередь посылает непростые к данным. Является перевалочным пунктом в цепочке получения данных. Очевидный недостаток – увеличение объема работы;
- использование iframe элементов. Данные элементы позволяют использовать скрипты со стороннего ресурса, через встраивание их на страницу. Использование данного метода сложно и небезопасно, а также не поддерживается многими браузерами.
Мы рассмотрели получение данных с одной стороны, со стороны клиента. За сервер может отвечать любая система, написанная на любом языке, достаточно, чтобы она умела обрабатывать HTTP-запросы. Тогда можно использовать архитектуру REST для построения веб-сервиса. Данная архитектура описывается 6 основными правилами и предоставляет лишь общие принципы, которые представлены в [2].
Существует множество более конкретных реализаций этих принципов, например JSON API. Эта методология определяет более детальные правила оформления системы запрос-ответ.
Компонентный подход позволяет четко определить каждую из вышеописанных задач в приложении. А структура с глобальным хранилищем состояний отлично интегрируется с асинхронными запросами к веб-сервисам. Например, при загрузке приложения вызывается Действие – получить данные по товарам. В этом слое приложения можно сделать запрос к стороннему сервису, а в Диспетчере обработать ответ. Таким образом слой взаимодействия с данными четко выделен и не зависит от веб-интерфейса.
В заключении к статье стоит сказать, что описанный подход не единственный и под конкретные задачи в него нужно вносить изменения. Поле решений в этой сфере очень велико, поэтому данная статья поможет начинающим разработчикам сформировать общее представление о будущем продукте.
Список литературы:
- Веб-документация MDN [Электронный ресурс]: офиц. сайт. – Режим доступа: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. – 12.05.2019.
- REST API Tutorial [Электронный ресурс]: офиц. сайт. – Режим доступа: https://www.restapitutorial.com/. – 12.05.2019.
- React JS [Электронный ресурс]: офиц. сайт. – Режим доступа: https://reactjs.org. – 12.05.2019.
- Redux JS [Электронный ресурс]: офиц. сайт. – Режим доступа: https://redux.js.org. – 12.05.2019.
- JSON API [Электронный ресурс]: офиц. сайт. – Режим доступа: https://jsonapi.org/. – 12.05.2019.
Оставить комментарий