Непонимание архитектуры потока в примере приложения чата

Я пытаюсь понять Пример приложения чата Flux. Авторы упоминают этот однонаправленный поток данных:

Однако в примере приложения есть зависимости между Action Creators (ChatMesssageActionCreator) и Stores (MessageStore) и между Stores (MessageStore, ThreadStore) и Web API Utils (ChatMessageUtils), что, по-видимому, противоречит правилу однонаправленного потока данных:

Рекомендуется ли следовать приведенному примеру или разработать лучший шаблон?

Update

Я понял, что ChatMessageUtils не принадлежит к Web API Utils, поэтому две стрелки из магазина не должны указывать на них, поэтому, возможно, они в порядке. Однако связь между ActionCreators и Store кажется странной.

Ответ 1

Пример немного принудительно, и он был создан с целью показать, как работает waitFor(). Аспект WebAPI в примере довольно искушен и действительно должен быть пересмотрен.

Однако, несмотря на то, что MessageStore.getCreatedMessageData(text) передает значение в хранилище, оно все равно является получателем. Это не настройка данных в магазине. Это действительно используется как метод утилиты, и хорошая ревизия (запрос pull?) Заключается в том, чтобы переместить этот метод в модуль Utils.

Чтобы улучшить пример для реального мира, вы можете сделать пару вещей:

Вызовите WebAPIUtils из хранилища, а не из ActionCreators. Это нормально, если ответ вызывает другой ActionCreator и не обрабатывается путем установки новых данных непосредственно в хранилище. Важно, чтобы новые данные происходили с действием. Важно, как данные поступают в систему, чем то, как данные выходят из системы.
Кроме того, для сообщений могут потребоваться отдельные идентификаторы на стороне клиента и серверной стороне. Там может быть немного преимуществ, таких как управление оптимистичными визуализациями. В этом случае вы можете создать идентификатор клиентской стороны в модуле Utils и передать этот идентификатор вместе с текстом как отправленному, так и WebAPIUtils.

Все, что сказал, да, пример нуждается в пересмотре.