Какую стратегию чище разделить излишки на ломтики?

Question

Я видел разные стратегии для разделения хранилища редуксов на куски (каждый срез имеет состояние, редукторы, action и actionCreators), и мне интересно, каковы плюсы и минусы каждой стратегии.

Разделение на основеБэкэнд-ресурсы

В остальном мире бэкенд-модели называются ресурсами.Так как интерфейс позволяет пользователю взаимодействовать с объектами этих классов, поэтому мы можем иметь срезы редукса, специфичные для каждого ресурса.

Пример. Срез для ресурса Post с состоянием, состоящим из ключей, таких как posts, selectedPost и т. Д.

Разделение на основе субмодулей внешнего интерфейса

Если вы рассматриваете подмодули как независимые разделы вашего приложения, каждому из них требуется свое собственное пространство имен в корневом хранилище.

Пример: фрагмент для подмодулей профиля, настроек и панели управления

Разделение по страницам приложения (или Маршрутам)

Каждая страница с маршрутом имеет свой собственный фрагмент.

Пример: страница настроек пользователя, страница настроек организации, страница настроек уведомлений, страница основных настроек

Также мне было интересно, есть ли другие стратегии, о которых я не знаю.

Answer 1

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

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

Answer 2

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

Если я правильно понял ваш вопрос, то вам не следует полностью полагаться на ресурсы BEопределить стратегию управления состоянием ваших функций, поскольку вам потребуется внутренняя гибкость для управления состоянием компонентов (флаги, счетчики, значения форм и т. д.).Следовательно, Стратегия 2 здесь пригодится.Наряду с тем, что вы определенно используете информацию BE, которая передается в тот же компонент.