CC BY
22OVERVIEW FLUX-ARCHITECTURE ON THE EXAMPLE OF STATE STORAGE OF JAVASCRIPT APPLICATION REDUX
Ovcharuk I.
PhD, Associate Professor of the Department of Information Technologies and Design, State University of Infrastructure and Technologies, Kyiv, Ukraine
Martyniuk A.
Master's degree student of the Department of Information Technologies and Design, State University of Infrastructure and Technologies, Kyiv, Ukraine
ОГЛЯД FLUX-АРХIТЕКТУРИ НА ПРИКЛАД1 КОНТЕЙНЕРУ СТАН1В JAVA-SCRIPT
ДОДАТКУ REDUX
Овчарук I.
к.т.н., доцент, доцент кафедри iнформацiйних технологт та дизайну, Державний yHieepcumem
тфраструктури та технологт, Кшв, Украна
Мартинюк А.
магктрант кафедри тформацтних технологт та дизайну, Державний утверситет тфраструктури та технологт, Кшв, Украна
Abstract
The article provides a detailed analysis of MVC technology and Flux architecture. The problems that arise when using the MVC (Model-View-Controller) template are considered, namely when actions lead to cascading updates, which, in turn, leads to unpredictable results and code that becomes difficult to debug. The article discusses the advantages of Flux-architecture, which eliminates these problems. The results are demonstrated on the developed application.
Анотащя
В статп докладно надано аналiз технологи MVC та Flux-архггектури. Розглянуто проблеми, що вини-кають при використанш шаблону MVC (Model-View-Controller), а саме, коли дп викликають каскадш оно-влення, що, в свою чергу, призводить до непередбачуваних результапв i коду, який стае важко вщлаго-джувати. В статп розглянуто переваги Flux-архiтектури, яка дозволяе усунути зазначенi проблеми. Результата продемонстроваш на розробленому застосунку.
Keywords: Flux-architecture, application state repository, controller, model, data section (view), repository, dispatcher.
Ключовi слова: Flux-архiтектура, сховище сташв додатку, контролер, модель, розрiз даних ( view), сховище, диспетчер.
Вступ. Flux-архгтектура - архiтектурний тд-хвд або Ha6ip naTepHÍB проектування для побудови користувацького iнтерфейсу веб-застосунку, в по-eднаннi з реактивним програмуванням. Flux-архiте-ктура побудована на односпрямованих потоках да-них.
Головною вiдмiнною рисою Flux е односто-роннiй напрямок передачi даних мiж компонентами архгтектури Flux. Архiтектура накладае обмеження на попк даних, зокрема, виключаючи можливють оновлення стану компонентiв самостiйно. Такий пiдхiд робить потiк даних передбачуваним i полег-шуе вiдстеження причин можливих помилок в про-грамному забезпеченнi.
Порiвняння Flux та MVC apxiTeKTyp. Щоб
краще описати noTÍK, nopÍBHaeMO його з однieю з проввдних клieнтських apxiTeKTyp: MVC. У ктент-ському застосунку MVC (рис.1) взаемодгя користу-вача запускае код у контролера Контролер знае, як координувати змiни в однiй або декшькох моделях, викликаючи вiдповiднi методи . Коли модeлi змь нюються, вони повiдомляють один або декшька ро-зpiзiв даних (View), яш, в свою чергу, читають новi дaнi з моделей i оновлюють себе вiдповiдно, щоб користувач Mir бачити ц новi дaнi.
-updates-
......user action events...............................................:
Model .....notifies —queries- View
Рис. 1. Схематичне зображення простого додатку MVC-арХтектури.
Оскшьки програма MVC зростае, а контро-лери, моделi та розрiзи даних (View) додаються, за-лежносп стають складнiшими. З додаванням всього трьох розрiзiв даних (View) (рис. 2), одного контролера i одше! моделi, графiк залежностi вже важче простежити. Коли користувач взаeмодie з ш-терфейсом, виконуються калька шляхiв коду розга-луження, i виникае проблема з налагодженням у
сташ програми, яка пов язана 3i з'ясуванням того, який модуль (або модул1) в одному (або дешлькох) з цих потенцiйних шляхiв коду мютить помилку. У гiршому випадку взаeмодiя з користувачем спричи-нить оновлення, як1, в свою чергу, викличуть дода-тковi оновлення, що призводить до помилок та кас-кадних ефектiв [1, с. 105].
Рис. 2. Схематичне зображення складного додатку MVC-apximeKmypu.
Flux уникае ще! конструкцп на користь однос-тороннього потоку даних. Уа взаемодп користува-чiв у розрiзi даних викликають дгю (Action Creator), що призводить до того, що подiя Action виклика-еться диспетчером (Dispatcher). Диспетчер е одшею
точкою виклику для всiх дiй у Flux-додатку. Дiя ввдправляеться вiд диспетчера в сховища (Store), яш оновлюються у ввдповщь на дш (рис. 3).
Action
Creator
г
Dispatcher dispatches ^ action ™ Store ■.....notifies ^—queries-
Рис. 3. Схематичне зображення простого додатку Flux-архтектури.
Потж ютотно не змiнюеться для додаткових станiв або розрiзiв даних (View). Диспетчер просто вщправляе всi дй' в yci стани в додатку. Причому, bíh не мютить знань про те, як насправд1 оновити
стан - саме сховище мiстить цю бiзнес-логiку. Ко-жен стан вiдповiдае за домен програми i оновлюе себе пльки у вiдповiдь на дд (рис.4).
Рис. 4. Схематичне зображення складного додатку Flux-архтектури.
Коли стан оновлюеться, вш запускае подш змши. У багатьох додатках React спешальш розрiзи даних (View) (вiдомi iнодi як "Controller-View") вь дповiдають за спостереження за шею подiею змiн, читання нових даних сташв та передачу цих даних через властивосп до дочiрнiх розрiзiв даних (View). У програмi React для поди змши стану, щоб викли-кати повторний рендеринг подання верхнього рь вня, ефективно ре-рендерить всю iерархiю подання (яка ефективно обробляе React). Це повнютю дозво-ляе уникнути складних помилок i проблем з проду-ктивнютю, як1 можуть виникнути через спроби спо-стерiгати за конкретними змшами властивостей моделей i лише незначно змiнювати частини розрiзiв даних (View) [2, c. 23].
Ключовi властивостi. Архитектура потоку за-безпечуе потiк даних явним, легко зрозумшим, на-дае можливiсть зб№шити локалiзацiю помилок i мае наступш властивостi:
- Примусова синхроннiсть. Ди (Actions) та 1х обробники (Handlers) всерединi сховища синхронна Усi асинхроннi операци мають викликати дш, яка поввдомляе системi про результат операци. Хоча ди можуть робити асинхроннi запити на сервер (API-call), обробники дш у сховищi в iдеалi цього не зроблять. Це правило робить потш шфор-маци в додатку надзвичайно явним; налагодження помилок у сташ застосунку просто включае в себе з'ясування того, яка дiя викликала поганий стан, а попм знайти неправильну логiку, яка ввдповша на цю дiю [3, c. 10].
- Iнверсiя контролю. Осшльки стани онов-люються всерединi сховища у вщповвдь на ди (а не оновлюються ззовнi контролером або подiбним модулем), жодна шша частина системи не повинна знати, як змшити стан програми. Вся лопка онов-лення стану мютиться в самому сховищi. I, осшльки сховище тiльки коли-небудь оновлюються у вщпо-вiдь на дц i тiльки синхронно, то шд час тестування сховища постае питання: поставити 1х у початковий стан (INITIAL_STATE), надiслати 1м дш та перевь рити, чи змiнився правильно стан.
- Семантичш ди. Оск1льки сховище повинно оновлювати себе у вщповщь на ди, то ди, як правило, е семантично описовг Наприклад, у Flux-програмi форуму, щоб позначити повiдомлення як прочитане, можна надiслати дш з ввдповщним типом MARK_THREAD_READ. Ддя (i компонент, що генеруе дiю) не знае, як виконати оновлення, але описуе, що вш хоче, щоб сталося. Через цю вла-стивють рiдко доводиться змiнювати типи дш, лише те, як на них реагуе сховище. До тих тр, поки ваша програма мае концепцш "потоку" i у вас е кнопка або шша взаемод1я. яка повинна позначати
поввдомлення як прочитане, тип ди семантично дш-сний [10, c. 116].
- Без каскадних дш Потш забороняе ввдправку друго! дй' в результат вщправки ди. Це допомагае запобити каскадним оновленням, як1 важко налагоджувати, i допомагае вам думати про взаемодш у вашому додатку з точки зору семан-тичних дiй.
Реалiзацiя Flux-архiтектури. На сьогодшш-нiй день е багато реалiзацiй Flux-архiтектури. Ось найпоширенiшi з них:
- Redux - це бiблiотека JavaScript з ввдкри-тим кодом для керування станом програми. Найча-стiше використовуеться в поеднанш з React або Angular для розвитку ктентсько! частини. Мютить ряд iнструментiв, як1 значно полегшують передачу даних сховища через контекст.
- Fluxxor - це набiр iнструментiв для полег-шення побудови шарiв даних JavaScript за допомо-гою Flux-архiтектури шляхом об'еднання багатьох основних Flux-концепцiй. Вiн особливо добре пра-цюе в поеднанш з React i мiстить калька помiчникiв, щоб полегшити iнтеграцiю з додатками React.
- MobX - це автономна бiблiотека для управ-лiння front-end станом програми. MobX забезпечуе узгоджешсть внутрiшнього стану штерфейсного додатку, надаючи зручнi iнструменти для його змши. Спрощено, MobX дозволяе реалiзувати лан-цюжок: «Виконати дш» ^ «Змшити стан» ^ «Змь нити вигляд». При цьому змши ввдбуваються атомарно i автоматично - в результата гарантовано, що не буде моменту, коли стан буде не узгодженим [11, c. 123].
- VueX - шаблон керування станом застосу-нку + бiблiотека для Vue.js додаткiв. Вiн служить централiзованим магазином для всiх компонентiв у додатку, з правилами, як гарантують, що стан може бути мутований лише передбачуваним чином.
- NgRx - це фреймворк для побудови реак-тивних додатшв в Angular. NgRx надае бiблiотеки для: управлiння глобальним та локальним станом, iзоляцiя побiчних ефекпв для просування бiльш чисто! архггектури компонентiв, управлiння зборами сутностей, штеграци з маршрутизатором. А також е шструментом, який покращуе досввд розробнишв при створеннi багатьох рiзних тишв додатк1в.
Приклад. Створимо додаток Узуальна час-тина не входить до розгляду статтi):
- Створимо пустий проект та виконаемо команду create-react-app
- За допомогою NPM шсталюемо ще низку бiблiотек (рис. 5):
dependencies": { "ramda": "л0.27.1", // Ha6ip корисних функц1й
"react": "л17.0.2", // Реакт вже встановяенний командою create-react-app "react-dom": НА17.9.2"# // Реакт-дом вже встановленний командою create-react-app "react-scripts": "4.0.3", // Реакт-скриптс вже встановленний командою create-react-app "react-redux": "л7.2.5", // б1блл.отека для зв'язки Реакт та Редакс "redux": "л4.1.1", // Redux.
"redux-thunk": "л2.3.0", // 61блд.отека для можливост! зв'язки i3 сервером, "reselect": "л4.0.0", // б1блд.отека для зручност± написания селектор1в
Рис. 5. Список залежностей додатку.
- Створимо Bei файли, яш нам знадобляться (рис. 6):
publish -/JS/publish
I components Ы App
¿1 App.js
зки.
index.js ¡fa .gitignore Й} package.json " README.md
Рис. 6. Структура проекту.
- У файлi constant.js (рис. 7) опишемо yei noTpi6Hi нам типи дш.
export default 1 T0D0_FETCH_LIST: '/todo/fetch/list', TODO_FETCH_SUCCESS: '/tado/fetch/success' TODO_FETCH_FAILURE: '/toda/fetch/failure *
TODO CREATE.ITEH: '/todo/create/itew', >;|
// Запит на отримання данних 1з серверу // Д1я у pa3i вдалого з'еднання // Щя у раз1 помолки з'еднання // Запит на створення данних на серверi
Рис. 7. constants.js.
- У файлi reduserjs (рис. 8) Створимо сховище, де будуть збертатися дат, помилки та флаг загру-
Рис. 8. reducer.js.
Також опишемо машпуляцп згiдно з типами. Коли вщправлено запит на сервер isLoading: true, коли сервер B^roBiB коректно, то у data записуемо вiдповiдь серверу, а якщо сталося помилка, тодi у error записуемо поввдомлення помилки. У разi не-ввдомо! ди сховище повертаеться до первiсного стану (INITIALSTATE).
- У файлi actions.js (рис. 9) опишемо двi ди. Запит серверу на отримання, та на зм^.
import CONSTANTS from './constants'; import API from '../constants/api'
export const fetchTodoList = () => async dispatch => { dispatch«
type: CONSTANTS.CREATE^FETCH^STATUS.
»;
9 try ■{
const clients = await API.get( 'todo/"); dispatch« type: CONSTANTS.TQDQ^FETCH^SUCCESS,
payload: clients.data, »;
} catch (error) ■{ dispatch« type: CONSTANTS.TOPO^FETCH^FAILURE, payload: error, »;
!6 > il > !2 |
export const createTodo = todo => async dispatch => {
Рис. 9. actions.js.
Висновки. В результат отримано веб-застосу-нок iз ввдокремленою графiчною частиною та лоп-чною.
За допомогою властивостi
__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ (рис. 10) можна спостерпати за icTopieio виклику
о О locdhost зоос
дiй та змiною станiв на кожному кроцi життевого циклу додатку. А це означае, що якщо десь розроб-ник допустить помилку, побачити ïï буде у рази ле-гше. На скршшоп видно, що пiсля запиту на сервер викликаеться дiя '/todo/fetch/failure' осшльки зазна-чено1 властивостi не юнуе.
chunk.]>1164:1S) at StHttpR*qu«>( honilrtrror (http:// tlc/js/Mndon-«atn. chunk. jt-.Ml: 14)"
[ tilcfltJSQNParsing: true, forccdJUtfarstn$: true, clart
Рис. 9. Середа розробки Redux у 6pay3epi.
СПИСОК Л1ТЕРАТУРИ:
1. Abramov D. Getting Started with Redux [Еле-ктронний ресурс] / Dan Abramov. - 2021. - Режим доступу до ресурсу: https://redux.js.org/introduction/getting-started.
2. Tilley M. What is Flux [Електронний ресурс] / Michelle Tilley. - 2014. - Режим доступу до ресурсу: http://fluxxor.com/what-is-flux.html.
3. Flux и Redux [Електронний ресурс] // Metanit. - 2021. - Режим доступу до ресурсу: https://metanit.com/web/react/5.1.php.
4. Catalin V. Изучаем архитектуру Flux в React [Електронний ресурс] / Vasile Catalin. - 2017. - Режим доступу до ресурсу: https://code.tutsplus.com/ru/tutorials/getting-started-with-the-flux-architecture-in-react--cms-28906.
5. Yangshun T. In-Depth Overview [Електронний ресурс] / Tay Yangshun. - 2019. - Режим доступу до ресурсу:
https://facebook.github.io/flux/docs/in-depth-overview.
6. MobX [Електронний ресурс] - Режим доступу до ресурсу: https://mobx.js.org/README.html.
7. Библиотека MobX [Електронний ресурс] // ТМ «Web Creator» - Режим доступу до ресурсу: https://web-creator.ru/technologies/webdev/mobx.
8. What is Vuex [Електронний ресурс]. - 2021. - Режим доступу до ресурсу: https://next.vuex.vuejs.org/.
9. What is NgRx [Електронний ресурс]. -2021. - Режим доступу до ресурсу: https://ngrx.io/docs.
10. Бодух А. Flux Architecture / Адам Бодух., 2016. - 352 с.
11. Garreau M. Redux in Action / M. Garreau, W. Faurot., 2018. - 312 с.
