Хранилища Redux обычно построены на концепции слайсов, , где весь набор данных разбивается на управляемые единицы, причем каждая единица является свойством объекта хранилища. Это позволяет вам кодировать каждый сегмент по одному, уменьшая объем кода, которым вы должны управлять в одном месте.
Существует два подхода: анализ данных по сравнению с анализом по функциям.
Когда хранилище настроено на основе данных, вы получаете преимущество, связывая свои данные сплоченным образом с точки зрения сверху вниз. Для того, что вы описываете, это имеет смысл, поскольку у вас есть четкие иерархические отношения в ваших данных. Затем действия могут быть определены CRUD-подобным образом.
Единственная проблема заключается в том, как именно вы управляете различными видами связанных данных. Если у вас есть разные данные в разных срезах, но вы должны поддерживать целостность идентификатора для разных наборов данных, вы можете в конечном итоге сделать несколько отправок между разными срезами, что может быть сложно. Конечно, вы можете хранить все свои данные в одном срезе, но это может раздуться.
Когда хранилище настроено по функции, каждый срез будет связан с действием в вашем приложении. Это может иметь больше смысла, если у вас есть разные «транзакции», такие как сайт розничной торговли с управлением профилями, покупки и блог поддержки сообщества. Разделение по функциям позволяет ограничить вопросы обновления одним фрагментом, что делает каждый тип данных, связанных с функцией, более управляемым. Он также позволяет вам поместить нарезанный код для функции в ту же папку, что и компоненты для этой функции, что делает ее хорошим комплексным пакетом.
Основная проблема с функцией слайс-за-функцией заключается в принятии решения о том, куда направляются данные. это может быть затронуто несколькими функциями. Общие или общие папки, или определение «домашней» папки, - это разные способы управления этим.
Итак, каков правильный ответ? Конечно, это зависит. Многое связано с тем, как вы хотите, чтобы ваше приложение работало. Это сильно обособленно? Тогда функции могут иметь смысл. Это в основном доступ к данным? Тогда срезы данных могут иметь смысл.
Вполне вероятно, что в итоге вы получите смесь из двух. У вас может быть основной «срез данных» с дополнительными функциональными срезами. Возможно, вы обнаружите, что один тип потока транзакций облегчает управление целостностью данных, чем другой, например, использование пути ввода в стиле мастера в сравнении со стилем произвольной формы «добавить узел в дерево».
One Последнее замечание: если вы хотите быстро управлять слайсами и использовать удобную встроенную философию и функции, я настоятельно рекомендую проверить Redux Toolkit . Он сделан теми же людьми, которые создали Redux, и применяет лучшие практики, которые они видели в дикой природе, чтобы сделать код редуктора и создателя действий управляемым и самодокументируемым.