Въведение в архитектурния модел на Flux

Discover Functional JavaScript бе обявен за една от най -добрите нови книги за функционално програмиране от BookAuthority !

Flux е архитектурен модел, предложен от Facebook за изграждане на SPAs. Предлага да разделите приложението на следните части:

  • Магазини
  • Диспечер
  • Изгледи
  • Създатели на действие / действие

Съхранявайте

Магазинът управлява държавата. Той може да съхранява както състоянието на домейна, така и състоянието на потребителския интерфейс.

Store и state са различни понятия. State е стойността на данните. Store е обект на поведение, който управлява състоянието чрез методи. В случай на управление на книги: списъкът с книги е състоянието и BookStore управлява този списък.

Магазинът управлява множество обекти. Това е единственият източник на истина по отношение на тези конкретни обекти. В едно приложение може да има много магазини. Например: BookStore, AuthorStore, UserStore.

В магазина няма методи за задаване. Можете да поискате промяна на състоянието само чрез предаване на действие на диспечера.

Магазин изслушва всички действия и решава кой от тях да действа. Това обикновено означава switchизявление. След като магазинът направи промени в състоянието, той ще излъчи събитие за промяна. Магазинът е излъчвател на събития.

Магазините не приемат други магазини като зависимости.

Диспечер

Dispatcher е единичен обект, който излъчва действия / събития за всички регистрирани магазини. Магазините трябва да се регистрират за събития, когато приложението стартира.

Когато влезе действие, то ще предаде това действие на всички регистрирани магазини.

Изглед

Изгледът е компонентът на потребителския интерфейс. Той е отговорен за изобразяването на потребителския интерфейс и за обработката на потребителското взаимодействие. Изгледите са в дървовидна структура.

Изгледите слушат промени в магазина и се изобразяват отново.

Изгледите могат да бъдат допълнително разделени в Изгледи на презентация и контейнер.

Изгледите на презентацията не се свързват с диспечер или магазини. Те общуват само чрез собствените си свойства.

Изгледите на контейнери са свързани с магазини и диспечер. Те изслушват събития от магазините и предоставят данните за презентационните компоненти. Те получават новите данни с помощта на публичните методи за получаване на магазините и след това предават тези данни в дървото на изгледите.

Контейнерът преглежда експедиционните действия в отговор на итерация на потребителя.

Действия

Действието е обикновен обект, който съдържа цялата информация, необходима за извършване на това действие.

Действията имат typeсвойство, идентифициращо типа действие.

Тъй като обектите за действие се движат около приложението, предлагам да ги направим неизменни.

Действията могат да идват от различни места. Те могат да идват от изгледи в резултат на взаимодействие с потребителя. Те могат да идват от други места като кода за инициализация, където могат да се вземат данни от уеб API и се задействат действия за актуализиране на изгледите. Действието може да идва от таймер, който изисква актуализации на екрана.

Създатели на действия

Практиката е да се капсулира кодът, създавайки действия във функции. Тези функции, които създават и изпращат действия, се наричат ​​създатели на действия.

Web API разговори

Когато правите извиквания на уеб API за актуализиране на потребителския интерфейс, извикването на уеб API ще бъде последвано от действие за актуализиране на магазина. Когато магазинът се актуализира, той ще излъчи събитие за промяна и в резултат изгледът, който слуша това събитие, ще се изобрази отново.

Извикванията на уеб API се извършват в създатели на действия. Можем да извлечем кода, който извиква API във функциите на Web API Utils.

Еднопосочен поток от данни

Актуализирането на изгледите протича в една посока:

Изгледите не променят данните, които са получили. Те изслушват промените в тези данни, създават действия с нови стойности, но не актуализират данните.

Магазини, изгледи и всякакви други действия не могат директно да променят състоянието в (други) магазини. Те трябва да изпратят действие чрез диспечера

Потокът от данни е по-кратък при четене в хранилището, отколкото при запис. Потокът от данни при запис в хранилището се различава между асинхронни и синхронни действия.

Съхранявайте четения

Съхраняване на записи в синхронни действия

Съхраняване на записи в асинхронни действия

Професионалисти

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

Действията могат да продължат и след това да се възпроизвеждат.

Минуси

Flux може да добави ненужна сложност към приложение, при което всеки изглед се съпоставя в един магазин. В този вид приложение е достатъчно разделение между изглед и магазин.

Погледнете например Как да създадете трислойно приложение с React.

Заключение

Магазините управляват държавата. Те променят състоянието си само чрез изслушване на действия. Магазините известяват изгледи за актуализиране.

Изгледите визуализират потребителския интерфейс и се справят с потребителското взаимодействие. Изгледите на контейнера слушат промени в магазина.

Диспечерът излъчва действия за всички регистрирани магазини.

Действията са обикновени обекти.

Открийте функционалния JavaScript беше обявен за един отнай-добрите нови книги за функционално програмиране от BookAuthority !

За повече информация относно прилагането на техники за функционално програмиране в React разгледайте Functional React .

Научете функционален React , по проект, базиран на функционална архитектура с React и Redux .

Следвайте в Twitter