ИСПОЛЬЗОВАНИЕ ПОДХОДА REDUX ПРИ ПРОЕКТИРОВАНИИ АРХИТЕКТУРЫ ВЕБ-ПРИЛОЖЕНИЯ

Информационные технологии, бурно развиваясь, проникают во все новые области человеческой деятельности. Не является исключением и такая область, как проведение социологических, в широком смысле этого понятия, опросов. Характеризуясь в качестве творческой, данная работа не свободна и от рутинных процедур, которые могут быть решены с помощью специализированного программного обеспечения. В [3] описан подход к созданию такой информационной системы, которая включает в себя сервер, предоставляющий разграниченный доступ к данным и возможность их изменения; мобильное приложение, используемое интервьюером непосредственно для опроса людей; веб-приложение, предоставляющего менеджеру возможности создания, изменения и удаления анкеты.

Одним из важных аспектов реализации рассматриваемого сервиса в части, касающейся веб-приложения, является его архитектура. На начальном этапе использовалось стандартное решение, предлагаемое фреймворком angular2. Несмотря на типичность рассматриваемой задачи, данный подход не свободен от недостатков, устранение которых представляется нетривиальной задачей. Традиционно, веб-приложение на angular2 состоит из набора компонентов (виджетов), которые образуют древовидную структуру [1]. В ней, в свою очередь, родительский компонент имеет ссылку на все вложенные в него дочерние. Обмен данными реализован следующим способом. При получении данных родитель отправляет их часть дочерним компонентам. Они, в свою очередь, либо передают их часть дальше по дереву компонентов, либо отображают эти данные с использованием различных элементов интерфейса. Также, в angular2 дочерние компоненты имеют возможность оповестить родительский о различных пользовательских событиях: клик мыши или нажатие клавиши. Также возможно внедрение так называемых сервисов (services) - специальных объектов, предоставляющих компоненту возможность получить данные в любой момент, вне зависимости от его расположения в дереве компонентов. Стоит упомянуть, что в angular2 реализован прием, позволяющий любому объекту веб-приложения получить доступ к другому, предварительно зарегистрированному объекту (provider) при необходимости.

При условии разработки архитектуры веб-приложения по одному из указанных подходов возможно возникновение следующих проблем [8].

Первая проблема - это обеспечение доступа к нужным данным всем компонентам, которые эти данные отображают. Дерево данных и дерево представления не всегда совпадают: “форма” данных часто не соответствует “форме” иерархии компонентов.

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

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

Для начала стоит отметить некоторые подходы к проектированию веб-приложения, решающие указанные выше проблемы[8]:

• Реактивный подход, использующий потоки данных и реакции на события в них. Вся разработка веб-приложения сводится к написанию этих самых реакций. RxJs является примером фреймворка, реализующим данный подход
• Flux - подход, использующий однонаправленный поток данных [5]. При нем, данные о состоянии веб-приложения содержатся в обособленных объектах — хранилищах (Stores). Также, существуют другие специальные объекты - отображения (Views), чья задача - отобразить эти данные. Далее, при любом значимом действии пользователя, генерируются дополнительные объекты — действия (Actions)[7], изменяющие данные в хранилищах. Об этом будут уведомлены все заинтересованные объекты приложения, в частности - отображения. Возникающий в данном случае однонаправленный поток данных упрощает понимание и поддержку кода.
• Redux, подход к проектированию веб-приложения производный от Flux. При его использовании, все данные о состоянии приложения представлены в виде единого объекта. Также, в redux данные, их структура и формат отделены от описания логики их модификации. Это основные отличия подхода redux от flux.

Все указанные подходы решают проблемы, о которых было сказано ранее. Однако, redux в данном случае наиболее прост для изучения и использования при проектировании архитектуры веб-приложения, поэтому, в данной статье более подробно будет рассмотрен именно он.

Основная идея redux - сохранение всех данных о состоянии веб-приложения в одном объекте. Эта идея может показаться немного странной, но как показывает практика, это способствует удобству в отладке и решению проблем с доступом к нужным данным.

Единственным объектом, способным изменить данные о состоянии приложения является хранилище (Store). При использовании подхода redux, приложение содержит одно и только одно хранилище.

Для изменения состояния приложения какой-либо компонент должен создать специальный объект ‘Action’, описывающий тип изменения и новые значения соответствующих данных состояния в хранилище. При архитектуре redux - это единственный способ изменить состояние приложения. Логика изменения состояния приложения описывается в специальной функции, называемой reducer. Данная функция принимает на вход 2 параметра: текущее состояние приложения и объект типа Action, который описывает, что нужно изменить в состоянии приложения. На выходе данная функция должна вернуть объект - новое состояние приложения. При изменении данных о состоянии приложения, хранилище уведомляет об этом всех заинтересованных объектов приложения.

Другой ключевой идеей redux, как производной от архитектуры flux является однонаправленный поток данных. Он начинается от событий пользовательского интерфейса и заканчивается уведомлением объектов об изменении определенных данных в состоянии приложения.

Представление возникающего потока данных показано на рис 1.

Рисунок 1. Поток данных при действии пользователя в архитектуре веб-приложения, созданного по методу Redux

Таким образом архитектура приложения, спроектированная по методу redux должна подчиняться следующим простым правилам[6]:

1. хранение состояния всего веб-приложения в одном объекте;
2. изменение состояния только с помощью создания специальных объектов называемых Action;
3. описание логики изменения состояния в виде функции называемой reducer.

Для объединения этих трех ключевых концепций текущие реализации redux используют объект, называемый хранилищем, о котором было сказано ранее. Хранилище предоставляет следующие возможности[4]:

1. сохранение начального состояния веб-приложения;
2. отправление какого-либо заранее созданного объекта типа "действие" для изменения состояния (функция dispatch);
3. назначение функции (reducer) для обработки изменения состояния.

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

Стоит отметить, что redux не пропагандирует использование какого-либо конкретного инструментария для реализации пользовательского интерфейса. На данный момент существуют реализации этой архитектуры, как для популярного фреймворка React, так и для нового angular2.

Стоит заметить, что redux задумывался как архитектура веб-приложения, сохраняющая возможность безболезненного добавления новых и изменения старых компонентов в больших, многофункциональных проектах со сложной логикой. Также стоит отметить, что уже существуют библиотеки, упрощающие разработку при использовании подхода redux [2]. К сожалению, большая их часть при использовании для разработки веб-приложений требует использования фреймворка React, что может иногда оказаться неприемлемым.

Список литературы:

1. Виктор Савкин Ключевые идеи приложения на angular2 [Электронный ресурс]. - Режим доступа: https://vsavkin.com/the-core-concepts-of-angular-2-c3d6cbe04d04 (дата обращения 10.04.2017)
2. Каталог библиотек, облегчающих использование подхода redux при разработке приложения [Электронный ресурс]. - Режим доступа: https://github.com/brillout/awesome-redux (дата обращения 10.04.2017)
3. Малаховская Е.К., Литвинюк В.А., Размахнин Н.А., Сидоров А.А. Облачный сервис подготовки, сопровождения и проведения полевого этапа социологических исследований: концепция // Научная сессия ТУСУР–2016: материалы Международной научно-технической конференции студентов, аспирантов и молодых ученых, Томск, 25–27 мая 2016 г. – Томск: В-Спектр, 2015: в 6 частях. – Ч. 4. – С. 132–133.
4. Описание объекта «Хранилище» в приложенни, спроектированом с использованием redux [Электронный ресурс]. - Режим доступа: http://redux.js.org/docs/basics/Store.html (дата обращения 10.04.2017)
5. Основные правила проектирования приложения с использованием flux [Электронный ресурс]. - Режим доступа: https://github.com/facebook/flux/tree/master/examples/flux-concepts (дата обращения 10.04.2017)
6. Основные правила проектирования приложения с использованием redux [Электронный ресурс]. - Режим доступа: https://github.com/reactjs/redux/blob/master/docs/introduction/ThreePrinciples.md (дата обращения 10.04.2017)
7. Структура объекта класса Action [Электронный ресурс]. - Режим доступа: https://github.com/acdlite/flux-standard-action (дата обращения 10.04.2017)
8. Nate Murray, Ari Lerner  Complete Book on Angular 2 [Электронный ресурс] - Режим доступа: https://www.ng-book.com/2/ (дата обращения 10.04.2017)