Управляем состоянием приложения без шаблонного кода и магии

[rumkin]

Плюс за метод remove!

Почему структура reducer'а "уплощается" в компоненте? В чью пользу разрешится конфликт имен, если у меня будут два одинаковых свойства в state и в actions?

[one_more]

при подписке входным параметром будет объект вида

{ [branchName]: branchState, action1, action2, ...actionN }

[Veikedo]

Но ведь это https://github.com/mobxjs/mobx-state-tree

[one_more]

не совсем

• MST подразумевает создание стора при инициализации приложения (иначе это уже не центральный стор)
• (поправьте если это не так) подписка происходит на весь стор
• 156кб может быть критично для большого приложения (против 3кб)

[valerqch]

Внешне получилось очень даже похоже на Vue с его компонентами, как мне кажется.

[bgnx]

возможность подписаться только на обновления всего стора (утомительные селекторы + возможны неожиданные перерисовки)

В примере из статьи компоненты по прежнему подписываются практически на весь стор — например при обновлении одной единственной тодошки будет оповещен весь список тодошек
хотя изменения касаются только одного компонента и нет смысла оповещать все остальные. Дальше неясно какую организацию стора предполагает библиотека чтобы работали подписки. Если это вложенные структуры то как библиотека предлагает обновлять данные которые находятся глубоко внутри объекта? В примере в статье предполагается иммутабельное обновление стора то как в этом случае предлагается работать с такой структурой — главный объект состояния хранит объект юзера, в нем хранится массив объектов folder, в каждой папке хранится массив объектов project, в каждом проекте массив объектов task в каждом задаче массив объектов comment и каждый комментарий может хранить вложенные объекты других комментариев и эти комментарии могут неограниченно вкладываться друг в друга — как библиотека предлагает обновлять текст глубоко вложенного в этом случае комментария? А если все же предполагается нормализация стора когда вместо объектов в массиве храним айдишники а все объекты будут храниться в хеше где айдишнику соотвествует объект то как будут работать в этом случае подписки?
А вообще тему подписок только на часть состояния без каких либо проблем с обновлением глубоко вложенных объектов (и также без необходимости нормализировать стор) я подробно разобрал в этой статье а в этой статье я разобрал разные по эффективности алгоритмы оповещения подписчиков

[one_more]

Если при обновлении одного todo не вызывать слушателей списка, то в данном случае не будет работать мета редюсер.
Что касается вложенности, такая структура легко преобразуется в плоский список — демо; это упростит структуру приложения и подписки будут работать ожидаемо

[xadd]

Это не Flux, у вас нет диспетчера и Action не как событие. Сегодня на фронтэнде без этого никак, иначе слишко будет легко. А вообще такой подход можно использовать в связке mobx/immer и получить как бонус точечное обновление компонентов.

[one_more]

Стоит отметить что dispatch есть — описано в секции api, и объект Action создается — он не прокидывается в другие редюсеры, но передается в middleware для возможности создания «сайд-эффектов»