Архитектура Flux, это я что-то не так понимаю?

Автор хотел бы, чтобы прочтение документации Redux и его исходного кода позволило полностью освоить идеи его дизайна и приемлемые способы использования. Вначале было непонятно, почему дизайн такой, затем стало ещё более непонятным.

1. Основные концепции Flux

Следующий текст взят с блога Ruanyifeng.

Во-первых, Flux делит приложение на четыре части:

• View: представление
• Action (действие): сообщения от представления (например, mouseClick)
• Dispatcher (распределитель): принимает Actions, вызывает обратные вызовы
• Store (слоистый уровень данных): хранит состояние приложения; когда происходит изменение, он сообщает Views о необходимости обновления страницы

Основной особенностью Flux является "одностороннее движение данных".

1. Пользователи обращаются к View
2. View отправляет действие пользователя
3. Распределитель получает Action и требует от Store соответствующего обновления
4. После обновления Store он выпускает событие "change"
5. View получает событие "change" и обновляет страницу

При этом данные всегда "односторонне перемещаются", никакие соседние части не имеют двустороннего движения данных. Это гарантирует ясность процесса.

2. Размышления над FluxЕсли одностороннее движение данных является ключевой частью здесь, то стоит задаться вопросом: в чем заключается ключ к реализации одностороннего движения данных? Распределитель!! Единый распределитель позволяет контролировать движение данных!!

Q: Но что такое распределитель?
A: Единый распределитель.
Q: Он распределяет что?
A: Распределяет события Actions.
Q: А что такое события Actions?
A: Сообщения от представления.
Q: Но ведь у меня много компонентов, много Actions, как избежать конфликтов в названиях? Как мне знать, какие Actions относятся к каждому компоненту? Как мне знать, какие Actions соответствуют структуре базы данных?
A: Почему ты задаешь столько вопросов!

Архитектура Flux объединяет многомерные компоненты в плоские структуры Store. Пользователю требуется заранее определить структуру Store, чтобы при инициализации Flux была известна полная структура Store.

Но хорошо ли это? Автор считает, что таким образом теряется гибкость, иногда временные переменные компонента остаются постоянно в объекте. Реализация распределителя в Redux состоит из большого switch-блока, который каждый раз проверяет триггер Actions. Почему это сделано именно так?

Вопросы:

1. Почему обязательно использовать огромное хранилище (Store)?

2. Акции действительно являются частью представлений (Views)?

3. Разумно ли проецировать древовидную структуру компонентов на хранилище без явной иерархии?Моё мнение следующее:

4. Это не обязательно, различные компоненты могут иметь свои собственные хранилища.

5. Акции не являются только частью представлений; они также могут быть разделены на более мелкие части.

6. Неразумно, необходимо позволять и проектировать различную комбинаторность уровней.

Примечание: структура Redux, написанная с использованием функций, действительно затрудняет понимание, а d.ts файлы кажутся слишком сложными!

Три: личное понимание архитектуры Flux

Хранилище (Store):

1. Как самый нижний уровень данных, должно иметь интерфейсы CRUD или команды.
2. Средний уровень — это действия (Actions), что соответствует концепции "транзакций" в базах данных. То есть, эта "транзакция" должна указывать, какие данные в базе данных должны быть изменены, как обрабатываться ошибки при модификации и так далее.
3. Реализация Dispatcher обеспечивает вызов имени действия ("Actionxxx"), параметров вызова для унифицированного обращения к действиям.
4. Создание нового хранилища осуществляется через наследование соответствующего абстрактного класса (в основе лежит паттерн прототипа).
5. Установка родительских отношений происходит путём вызова встроенных методов в конструкторе хранилища.
6. Отвязка от родительских отношений аналогично производится.
```### Dispatcher:

Необходимо привязываться к хранилищу, Есть единой реализации, которую можно переопределить, Содержит встроенные методы для вызова middleware, а также для вызова событий хранилищ.

### Представление (View):

Древовидные компоненты, Локальные хранилища создаются по необходимости, а также устанавливаются связи между ними. События уровня представления Event должны одновременно вызывать соответствующие действия, поддерживают асинхронные функции.

### Действия (Actions):

Разделены на События представлений (Views) и действия хранилищ (Stores)

![](https://oscimg.oschina.net/oscnet/1289b1a18e6b3dd6df24e2915d30b8a074c.jpg "Моя персональная архитектура Flux")

Это моя персональная архитектура Flux.

При создании иерархии хранилищ родительских уровней, dispatcher будет обращаться к EventPool.

Классы, наследующиеся от хранилища, могут переопределять действия, dispatcher