Существует множество частных интерпретаций основного принципа управлением данных. Непохожие друг-на-друга вариаций MVC от google, apple, facebook, microsoft, etc… и другие мутаций MVP/MVVM/MV* - зачастую не раскрывают главной идеи управления состоянием. Flux/Redux/Vuex/Mobx - так же являются частными случаями реализации главной идеи, но уводя внимания в частности от основных форм состояния данных.
Возникновение термина MVW (Whatever) - говорит о важности представления и модели данных существующих во всех реализациях. Остальные термины описывают частные случаи перехода состояния из байтов базы данных в картинку на экране пользователя. Потому основную идею лучше рассматривать на примере воды и её круговороте в нашем мире. Именно круговорота. Так на каждом участке есть частное движение в обе стороны - основная идея потока в испарении через океаны и выпадением осадков на континенты. Так запускается действие функций жизни земли. Подобно переходам состояния воды из газообразного в лёд горных вершин - данные пользователя путешествуют от сервера клиенту и обратно. Важно видеть воздействие пользователя на данные так же как солнце на воду.
Так суть всех редьюсеров, контроллеров, мутаций, диспатчеров, и.т.д. станет ясной, в движении данных от пользователя или обратно. Осадки или испарение.
Основной принцип движения данных от пользователя к состоянию байтов (операции/база данных) и обратно.
Все фреймворки управления состоянием клиента иного не делают.
Каждый вправе по своему называть промежуточные этапы движения необходимые в среде их возникновения. Зачастую нет малейшей нужды в некоторых этапах принятых в фейсбуке. А бывает нет возможности предсказать какие понадобятся промежуточные мутации и глубина веток дерева машины состояний. Когда бизнес-логике вернее прямые связи запрещённые фреймворком как антипаттерн. Так получается лапша из десятков связей данных путешествующих по миру/графу исключительно в нуждах отсутствующего контекста среды разработчиков фреймворка.
Идеи State Action Model и MobX State Tree наиболее похожие на наш подход к управлению состоянием.
Функционально-реактивная культура кода - фантастически эффективная, но стремится к фантазиям.
- Важно четко видеть потоки бизнес логики, соединительный узлы и проходящих в них мутации.
- Уловить технику "безшовного" переливания данных по графу из одного потока в другой.
- Понять точки входа и выхода в автомат состояний.
В настоящих фяп отсутствует оператор присваивания, а данные текут в монадах, функторах и т.д.
Близкой по смыслу к нашим задачам оказалась библиотека flyd, а дальше всех RxJs. В будущих стандартах возможно появление Object.observe или подобных Proxy решений для имплементации базовых реактивных объектов.
Когда браузеры не умели даже Proxy, для манипуляции реактивным клубком состояний я сделал библиотеку Alak. Первая версия в пару десятков строк кода делала всё необходимое нужно от flyd без необходимости таскать импорты для взаимодействия с сущностью в лаконичном стиле. Год назад библиотека переехала на Proxy и помимо состояния функторы обрели метаданные. Но основные два момента необходимых для понимания остались неизменными:
//создание потока
let f = A.flow
//получение данных из потока реактивно
f.on(v=> …)
//получение состояния данных из потока декларативно
f.v
//передача данных в поток
f(“some_data”)В примере Alak Simple Fibo State модель состояния имет вид:
{
offset: A.flow(2),
count: A.flow(3),
result: A.flow
}
и одно действие doFibo для изменения узла result
Run Simple Fibo on codesandbox.io
Для управления представления DOM можно использовать любой самодельное или модное решение вроде react, vue, etc... В следущем примере для этого попрежнему использутся простая render функция. https://codesandbox.io/s/m7v933zpyp
...а в следующем обновлении о самом инстроменте управления стейтом для vue.