Я пытаюсь выяснить, как лучше всего справиться с довольно распространенной ситуацией в приложениях средней сложности с использованием архитектуры Flux, как получить данные с сервера, когда модели, составляющие данные, имеют зависимости между ними. Например:
Веб-приложение магазина имеет следующие модели:
- Тележки (у пользователя может быть несколько тележек)
- Продавцы
- Товары
С каждой из моделей связан магазин (CartsStore, VendorsStore, ProductsStore).
Предполагая, что продуктов и поставщиков слишком много, чтобы они всегда были загружены, моя проблема возникает, когда я хочу показать список тележек.
У меня есть иерархия компонентов React.js:
- CartList.jsx
- Cart.jsx
- CartItem.jsx
- Cart.jsx
Компонент CartList извлекает все данные из хранилищ и создает список компонентов корзины, передавая определенные зависимости для каждого из них. (тележки, продавцы, продукты)
Теперь, если бы я знал заранее, какие продукты и поставщики мне нужны, я бы просто запускал все три запроса к серверу и использовал бы waitFor в Магазинах для синхронизации данных, если это необходимо. Проблема в том, что пока я не получу тележки, я не знаю, каких поставщиков или продукты мне нужно запросить на сервере.
Мое текущее решение состоит в том, чтобы обработать это в компоненте CartList, в getState я получаю тележки, продавцов и продукты из каждого из магазинов, а в _onChange я делаю весь поток:
Это работает на данный момент, но есть несколько вещей, которые мне не нравятся:
1) Поток кажется мне немного хрупким, особенно потому, что компонент прослушивает 3 хранилища, но есть только точка входа для запуска «что-то изменилось в событии данных», поэтому я не могу различить, что именно изменилось и правильно реагировать.
2) Когда компонент запускает некоторые из вложенных зависимостей, он не может создать какое-либо действие, потому что находится в методе _onChange, который считает, что все еще обрабатывает предыдущее действие. Flux это не нравится, и он запускает «Невозможно отправить в середине отправки», что означает, что я не могу инициировать какое-либо действие, пока весь процесс не будет завершен.
3) Из-за единственной точки входа достаточно сложно реагировать на ошибки.
Итак, альтернативное решение, о котором я думаю, состоит в том, чтобы иметь логику «композиции модели» в вызове API, иметь модель-оболочку (CartList), содержащую все 3 необходимые модели, и хранить ее в магазине, который будет только получить уведомление, когда весь объект будет собран. Проблема в том, чтобы реагировать на изменения в одной из подмоделей, поступающие извне.
Кто-нибудь нашел хороший способ справиться с ситуациями с компоновкой данных?
