Зачем держать магазины неприкосновенными для создателя действий на Facebook Flux?

Я читаю про Facebook Flux, и мне понравился паттерн, но я не понимаю, зачем нам держать магазин неприкосновенным для создателя экшена. Facebook только говорит, что это часть «разделения интересов», и только магазин должен знать, как изменить себя. Facebook не согласен с установщиками магазина, такими как «setAsRead», но не запускает ли событие создателя действия через диспетчер, которое захвачено в магазине, почти одно и то же? И вызов чего-то вроде «setAsRead» не показывает, как хранилище изменяет себя.

Некоторые говорят, что это вызывает связь между магазином и создателем действия, но запуск событий в диспетчере вызывает связь между публикацией/подпиской, магазином и создателем действия.

Сохранение магазинов неприкосновенными для создателя действия создает потребность в «waitFor». Цепочки ожидания не создают более неявной связи между магазинами? Если какое-то действие требует взаимодействия в определенном порядке, почему это еще не сделано для создателя действия?

Знаете ли вы, ребята, минусы использования бездиспетчерского подхода с Facebook Flux?


facebook store flux
person Chad Weston    schedule 28.06.2015    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Если вы реализуете сеттеры в своем магазине, вы полностью нарушите принцип однонаправленного потока данных, который, возможно, является центральным принципом Шаблон потока. Ничто не помешает вашим компонентам или любому другому коду напрямую управлять состоянием хранилища. Теперь мутации данных больше не происходят только из хранилищ, реагирующих на действия, поэтому у вас есть много «источников правды».

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

Actions ----> Stores ----> Components
   ^                           |
   |___________________________|

waitFor на самом деле создает связь между хранилищами, и она просачивается в Dispatcher, который должен обеспечивать функцию waitFor. Возможно, это один из наиболее спорных моментов «ванильного» шаблона Flux, и, например, Reflux реализует его по-другому. , без центрального диспетчера.

person Hannes Johansson    schedule 02.07.2015