Структура

В моем приложении я использую React и Reflux и имею иерархическую настройку в отношении моих данных. Я пытаюсь разбить элементы моего приложения в отдельных магазинах, чтобы иметь возможность правильно подключать события и отдельные проблемы.

У меня есть следующий поток данных:

Workspaces -> Placeholders -> Elements

В этом случае, когда создается рабочее пространство, в свою очередь создается заполнитель по умолчанию с ссылкой (ID) во вновь созданное рабочее пространство. То же самое относится к взаимозависимости между элементами.

Точка фиксации

Образ Reflux, по-видимому, предполагает, что PlaceholderStore прослушивает триггеры из WorkspaceStore, добавляя вновь созданный идентификатор к this.trigger().

Reflux позволяет только одно событие запускаться из хранилищ; что позволяет внешним компонентам распознавать действия create или update. Это означает, что если один триггер в хранилище отправляет идентификатор как argument[0], последующие триггеры должны делать то же самое (чтобы оставаться последовательным). Это проблема для компонентов, которые ищут обновления для нескольких рабочих областей (например, переупорядочивание/массовые обновления).

Нежелательное решение

Я подумал добавить концепцию StoreActions; Действия, которые могут храниться только в магазинах, могут создавать другие магазины, которые затем прослушивают (фактически отбрасывая исходный триггер из магазинов). Благодаря тому, что эти компоненты/магазины могли прослушивать определенные события, и аргументы, переданные указанным событиям, могут быть адаптированы без проблем. Это кажется неправильным способом и злоупотреблением системой событий Reflux.

Справка

Должен ли я пытаться разбить связанные данные? Есть ли лучший способ структурирования данных?

Я читал об агрегированных магазинах, но не видел каких-либо реализаций для анализа. Предлагают ли они решение путем совместного использования данных из нескольких магазинов, и если да, то что отвечает за создание событий. Компоненты React могут прослушивать?

Большое спасибо за любую помощь/понимание, которое любой может предложить!

Ответ 1

Да, вполне разумно называть действия из магазина. Я вижу действия как инициаторы потоков данных, и я рассматриваю исключительные потоки как отдельные.

Хорошим примером является хранилище CRUD, которое также обрабатывает вызовы AJAX (для CRUD данные с серверной стороны). Магазин инициирует событие изменения, как только данные будут обновлены. Однако в случае сбоя вызова AJAX вместо этого вместо этого следует вместо этого начать поток данных, чтобы другие магазины и компоненты могли прослушивать их. С моей точки зрения такие ошибки отвечают интересам компонента тоста/уведомления и журнала ошибок Google Analytics, таких как Исключения GA.

Пример AJAX также может быть реализован с помощью крюка preEmit в действиях, и есть несколько примеров из обсуждения проблем github. Существует даже этот помощник асинхронных действий.

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