Flux&&React вопросы по архитектуре?

Question

[Дмитрий Спиридонов]

Всем доброго времени суток. Поначитавшись статей на хабре про данные технологии, решил попробовать переписать приложение на сие чудо. Но заглядывая вперед, сразу вижу несколько вопросов, которые не понимаю. Заранее благодарю за любые советы по ним
1) В самой идее Flux зашито, что с данными может оперировать только хранилище(store), только оно знает как манипулировать данными(как я понял, конечно может быть я ошибаюсь). Но тут встает вопрос, скажем у меня есть 2 отдельных компонента, и скажем клик по одному открывает второй компонент. В данном случае я должен эту манипуляцию пропускать через хранилище, создавать в нем какой-то флаг _isOpen, и вешать changeListener, или же я могу пропускать такие вещи через какой-то общий их компонент?
2) Как осуществляется манипуляция данными между хранилищами? Предположим у меня есть 2 хранилища: dataStore, orderStore. При создании заказа, мне потребуется изменить какие-то данные в dataStore. Как быть в данном случае, могу ли я инжектить orderStore в dataStore, или же в данном случае цепочка идет такая: ловлю во view-controller ивент, что создался заказ, и сразу же говорю диспетчеру, чтобы он дернул dataStore?
3) Как быть с socketio? Правильно ли я понимаю, что ему место во view? то есть вьюха ловит сокет и начинает традиционную цепочку action->dispatcher... Или же я могу вставить socket.on(...) в хранилище и сразу там начать изменять данные?
4) Вопрос скорее дискуссионный. Нельзя не заметить, что на реакте писать приходится в разы больше, чем на том же ангуларе. Но вопрос такой: насколько дольше по времени идет разработка на реакте, в сравнении например с ангуларом, эмбером?

Answer 1

[Андрей Антропов]

Для начала хочется пару общих слов относительно Flux, все будет зависеть от реализации это архитектуры, то что предлагается непосредственно FB слишком многословно получается и, забегая вперед, возможно с этим ассоциируется многословность из пункта 4.
В своих проектах на React я использую реализацию Refluxjs одна из самых популярных альтернатив к FB.
Свои ответы построю как сравнение между реализацией FB и Reflux
1. По классической схеме да нужно хранилище для этого флага, в Reflux диспетчера центрального нет и события получают только реально заинтересованные слушатели, поэтому такие вещи можно упростить и слушать просто выброс события типа

mixins : [
  Reflux.listenTo(AActions.toggleOpen, 'onToggleOpen')
]

в котором просто сделать setState с новыми параметрами, если компонентов которые должны будут слушать станет больше одного можно очень легко отрефакторить на хранилище, благодаря миксинам для хранилищ создание хранилища можно уместить в пять строчек кода.
2. Идея вторая более правильная, и именно в таком виде ее можно реализовать в FB, для Reflux один стор может слушать изменения в другом и соответственно может при необходимости изменять свое внутреннее состояние с возбуждением события
3. Не обязательно вьюха, просто код который инициализирующий сокеты, для классики это SERVER_EVENT, в Reflux можно прямо в качестве хэндлера события можно экшн навесить
4. Все зависит от реализации ;) для меня связка React+Reflux+Immutable помноженное на чистые функции очень лаконична и читабельна

Comments

[Дмитрий Спиридонов]

Огромное спасибо за столь развернутый ответ!

[Дмитрий Спиридонов]

Андрей, подскажите, как обстоят дела у Reflux с server-side prerendering? Вопрос созрел собственно из-за этого: https://github.com/webpack/items-store/issues/3

[Андрей Антропов]

Дела обстоят хорошо по причине наличия https://www.npmjs.com/package/isomorphic-reflux также можно посмотреть в сторону https://www.npmjs.com/package/ambidex хотя бы в качестве примера использования рефлакса

[Дмитрий Спиридонов]

Благодарю!