Привет, это основное введение в архитектуру Flux. В этой статье мы обсудим использование архитектуры потока, почему Facebook использовал ее и сравнение с архитектурой MVC.

Что такое архитектура Flux?

Flux - это архитектурный шаблон, предложенный Facebook для создания SPA (одностраничных приложений). Это не какая-то структура, это просто архитектура или шаблон для создания клиентских веб-приложений. Он был разработан в facebook вместе с библиотекой React View.

Детали и история архитектуры Flux

В статье Цзин Чен, оригинального создателя Flux, говорится, что Facebook столкнулся с некоторыми проблемами в своем приложении, и Facebook пришел к выводу, что структура MVC ошибочна и не может масштабировать их потребности. Итак, Facebook решил использовать другой подход, и затем была представлена ​​архитектура Flux.

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

В соответствии с ним, когда пользователь вызывает действие, контроллер обрабатывает его и вызывает метод внутри модели, который может привести к повторному рендерингу одного из представлений. Но в таких больших приложениях трудно понять и отладить двунаправленный поток данных между моделями и представлениями, поэтому они представили архитектуру Flux, которая является однонаправленной, и предложили следующий дизайн Flux.

Теперь, согласно этой архитектуре потока, есть несколько основных частей архитектуры. Итак, сначала давайте обсудим их.

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

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

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

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

Теперь давайте подведем итог приведенной выше диаграмме в небольшое примечание.

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

Эта однонаправленная структура показывает, что архитектура проста и последняя версия данных всегда представлена ​​уровнем представления приложения.

Почему именно Flux Architecture?

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

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