Рассмотрим следующее типичное приложение CRUD:
Уровень данных
Модель реляционной области с отношениями один-к-одному, один-ко-многим и многие-ко-многим между сущностями. Объекты сохраняются в реляционной базе данных.
Уровень обслуживания
Сервисный уровень предоставляет API-интерфейс REST для обработки GET, POST, PUT и DELETE методов на объектах для выполнения бизнес-транзакций.
Уровень состояния клиента
Состояние клиента управляется контейнером состояния Redux. Redux хранит представление сущностей на уровне данных и ожидающие транзакции на них. Промежуточное программное обеспечение Redux используется для обеспечения большей гигиены и упрощения анализа кода.
Презентационный слой
Пользовательский интерфейс реализован с использованием React с рендерингом на стороне клиента. Внутренние состояния компонентов используются для управления второстепенными состояниями как «прелюдия» к инициированию транзакций с большей кистью (действия Redux).
Каков наилучший подход к структурированию состояния Redux, редукторов, действий и подписок для сложной модели домена? Конечно, свести к минимуму дублирование кода, но при этом обеспечить слабую связь и независимые действия над объектами? Кроме того, лучше ли управлять «несохраненными изменениями» и логикой проверки внутренних состояний компонентов?